fix(dynamic_parser): Handle reserved words correctly. #614
Conversation
Conflicts: lib/core/scope.dart
…arser to be consistent with the code generation path.
| @@ -78,3 +78,43 @@ relaxFnArgs(Function fn) { | |||
| } | |||
|
|
|||
| capitalize(String s) => s.substring(0, 1).toUpperCase() + s.substring(1); | |||
|
|
|||
|
|
|||
| /// Returns whether or not the given identifier is a reserved word in Dart. | |||
There was a problem hiding this comment.
Possibly include the URL that was given in reserved_dart_keywords.dart, namely:
// From https://www.dartlang.org/docs/spec/latest/dart-language-specification.html#h.huusvrzea3q
If not to the specific section, at least to the language spec.
|
IMHO, this issue is related to the following broader issue: #606, "Treat Dart maps like maps, not (JavaScript) objects with field access". This PR (#614) takes AngularDart even further away from Dart and goes against the principle of least surprise (a principle that has been used to guide the design of Dart itself and should probably be used to guide the design of AngularDart too). It certainly makes sense to support map key values that happen to be Dart reserved words, but, I don't think we would support fields with names that are reserved words. Btw, is this fix (#614) in high demand? Or is it being inspired form AngularJS functionality? If the later, then we should question the wisdom of it. |
Reminded about this by Kasper Lund’s dart-archive#614.
Make sure the dynamic parser deals with reserved words correctly and in a way that's consistent with how they behave when using code generation.