Symbol should expose the actual symbol name

[Hixie]

It knows it, since it's in the toString, but it's not easily extracted.

[matanlurey]

This is with the realization that the actual name might be 'v' with minification applied, right?

(There is a way to do this with dart:mirrors - but that is for getting the "real name")

[Hixie]

In my case I only care about the VM case, in particular the VM case in checked mode, where there's never minification as far as I know. I agree that this would be less useful in other modes.

In the context where I'm using this (Flutter's flutter_test test harness), we don't have dart:mirrors unfortunately.

Having said all that, if dart:mirrors can do it, why couldn't Symbol just do it itself? If dart:mirrors can do it then the data is there, right? Minification or no?

[rmacnak-google]

This is by design. Mirrors traffick in Symbols instead of regular Strings to make minification easier for dart2js, by requiring one to both import 'dart:mirrors' and use a static method perform conversions.

[eernstg]

If dart:mirrors can do it then the data is there, right? Minification or no?

The typical situation (dart2js compilation is one example) is that import 'dart:mirrors'; causes compilation to preserve more information about the program than would otherwise have been necessary. So the data can be made available if you tell the compiler that it must be available. The downside is that this may turn a 14kB program into a 1.9MB program (comment out one or the other declaration of showName):

import 'dart:mirrors';

class HelloWorld {}

String showName(o) => "HelloWorld";

String showName(o) {
  TypeMirror oType = reflect(o).type;
  return MirrorSystem.getName(oType.simpleName);
}

main() {
  var x = new HelloWorld();
  print(showName(x));
}

Even though the vm may have the information in any case, it wouldn't be able to deliver it "for free" without destroying the portability of the code. So you have to use mirrors to get at this information.

[Hixie]

I feel like this is a "least common denominator" decision, where the VM experience suffers because of a limitation of one of the other targets.

The reality of the situation is that I need to make the Flutter test harness error messages usable, which means showing the actual names of the symbols that I collect from a mock that is collecting Invocations via noSuchMethod. Today I do this by extracting the name from the Symbol.toString() using very brittle substring manipulation. I think it would be better if, when the information is available, it was exposed via a cleaner API.

Since the use case is for tests only, it doesn't matter if it only works in the checked mode, non-AOT, non dart2js target that flutter test uses. Yes the code isn't portable, but we've already crossed that bridge since the code depends on dart:ui which isn't available anywhere else either.

[lrhn]

We do expose the name in the toString. We should either stop doing that, or admit that we expose it and make a better API for it (e.g., a name getter). Right now we effectively have a string based API that requires the user to parse the string to extract the available information.

Sadly, the same argument goes for the toString methods of Type and Object.

That doesn't meant that we have to use the un-minified name in a minified program. We can return the minified name, if that is what we show in the toString result. We might want to, but we don't have to. A minified program that doesn't create new symbols from strings at runtime, and which doesn't use MirrorSystem.getName(symbol), can just keep only the minified names. Not particularly readable, but you did ask to have your program minified!

[tvolkert]

Sadly, the same argument goes for the toString methods of Type and Object.

And Function too