Is this using the dart2dart minifier?

Added NeedsInfo label.

This comment was originally written by fra...@igindo.com

I only tested using dart2js, however dart2dart would probably have the same problem?

Thanks for the update.

Added Area-Dart2JS, Triaged labels.
Changed the title to: "dart2js: runtimeType.toString() is wrong when using minify".

As far as I know, this is the expected behavior.

cc @gbracha.

This comment was originally written by fra...@igindo.com

I use runtimetype to dynamically add default CSS styles at runtime,
mirrors would be a valid alternative, but won't that imply a performance penalty over using something simple like runtimeType?

Perhaps you could provide a new type property next to runtimeType which holds the original class name as a String?

The underlying problem is this: a big part of the size reduction we achieve with minification is due to using shorter names. Retaining the original name is adds an overhead which we deem is too large.

We are working on solving these issues, but if you really care about download size, you'll probably have do something like this:

getName(foo) {
  if (foo is DivElement) return 'DivElement';
  ...
}

We'll probably add annotations to control which names are preserved and which aren't. In that case, you might be able to write something like this:

@UseClassNames(subclassesOf: const [Element])
getName(foo) => '${foo.runtimeType}';

Added this to the Later milestone.

Added TriageForM5 label.

Removed TriageForM5 label.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.

Issue #20457 has been merged into this issue.

This comment was originally written by youyou333...@gmail.com

I think it would be better to mention this behavior in runtimeType doc until this is fixed

This is not just a minification issue. All classes have different JavaScript names, and the JavaScript name is strongly related (1-1) to the runtimeType name. We would have to substantially change the type representation to fix this. I'm not saying we should not fix this, just that it has a nontrivial implementation cost.

We could store the full name against the minified name. This would increase the size of minifed programs by about 5%. Many of our customers do not believe this cost is justified and would need a way to make it opt-in.

A consequence of the 1-1 correspondence is that even unminified programs can print the 'wrong' name.
The following program prints:

Thing
Thing0

-------- 9217.dart --------
import '9217a.dart' as a;
import '9217b.dart' as b;

main() {
  print(new a.Thing().runtimeType);
  print(new b.Thing().runtimeType);
}
-------- 9217a.dart --------
class Thing {}
-------- 9217b.dart --------
class Thing {}

I have same error with JSON Object. On Android, it is _InternalLinkedHashMap<String, dynamic>, on Web it's _JsonMap. But on release is mininy:ds. Don't use dynamic.runtimeType, replace with "object is Map<String,dynamic>" instead

Found this to be a problem manifesting when building a Flutter project for release, if built for debug, the names where correct. example:

...
await ApiGuardSystemsService().getAssets(
...
  ).then((rawAssets) async {

    print("rawAssets.runTimeType = ${rawAssets.runtimeType.toString()}");

    if(rawAssets.runtimeType == List<dynamic>) {
      await globals.mOfficeDatabase.transaction(() async {
        for (var rawAsset in rawAssets) {
          print("inserting rawAsset");
...
    print("getAssets done !");
   });  

Here I get the following print results in console:
Debug build:

rawAssets.runTimeType = List<dynamic>
inserting rawAsset
getAssets done !

In release build:

rawAssets.runTimeType = minified:H<dynamic>
getAssets done !

You see, my expected type check didn't checkout because the expected runtimeType is different in release vs debug...

Will file an issue for this in Flutter/dart...

Thanx for mentioned this here!

@RoarGronmo Don't compare types like this. Use is checks instead. <dynamic>[].runtimeType is not guaranteed to be exactly List<dynamic>, it can be _SomeImplementationOfList<dynamic>.

Object.runtimeType exists primarily for debugging purposes (e.g. to print it), any sort of code that dispatches on it should be avoided. Type.toString is not guaranteed to return any readable form of the type that has any relationship to the original source. For convenience reasons implementations tend to return something that either matches name in the source or can be mapped back to the original source through deobfuscation map, but this is not really a specified behavior and any reliance on it should be avoided.

Well...
My undestanding of dynamic is beginning to be loose...

When it says it is just dynamic at first..

I feel I have a "right to know" what type of the dynamic actually is.