{"comment":{"url":"https://api.github.com/repos/jakemac53/reflectable/comments/12421070","html_url":"https://github.com/jakemac53/reflectable/commit/d3ac6aca7178beefd8b6886552e9471b13b71c6b#commitcomment-12421070","id":12421070,"user":{"login":"jakemac53","id":984921,"avatar_url":"https://avatars.githubusercontent.com/u/984921?v=3","gravatar_id":"","url":"https://api.github.com/users/jakemac53","html_url":"https://github.com/jakemac53","followers_url":"https://api.github.com/users/jakemac53/followers","following_url":"https://api.github.com/users/jakemac53/following{/other_user}","gists_url":"https://api.github.com/users/jakemac53/gists{/gist_id}","starred_url":"https://api.github.com/users/jakemac53/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jakemac53/subscriptions","organizations_url":"https://api.github.com/users/jakemac53/orgs","repos_url":"https://api.github.com/users/jakemac53/repos","events_url":"https://api.github.com/users/jakemac53/events{/privacy}","received_events_url":"https://api.github.com/users/jakemac53/received_events","type":"User","site_admin":false},"position":null,"line":null,"path":"","commit_id":"d3ac6aca7178beefd8b6886552e9471b13b71c6b","created_at":"2015-07-29T14:05:24Z","updated_at":"2015-07-29T14:05:24Z","body":"> thanks for the input! Could you motivate why you prefer raw strings in generated code? Preventing code injection security issues? Misinterpretation of string escapes (like \"\\n\" getting interpreted an extra time)? I cannot readily see any cases where things like '\"${getterName}\"..' would be affected. That said, it's certainly likely that we should use raw strings in generated code, but making the rationale explicit would we helpful.\r\n\r\nThis is to get around escaping issues in the generated code. The specific issue I ran into was we have a getter called `$` (to align with polymer js). In the generated code this becomes `\"$\"` which is not a valid string as the `$` should be escaped. The raw string method is a simple and most effective way I to fix these sorts of issues.\r\n\r\n> On the type annotation changes: IntelliJ says \"No problems found in Dart code\", make check in 'tool' shows no errors nor warnings, and yes, it does run on the package bots (all green). But in general it seems to be cases where the current type annotation relies on an implicit downcast (one side of assignability), e.g., from Iterable<String> to List<String>. It should of course be Iterable<String> such that we avoid this unnecessary downcast. It would have been nice to have an option on the tools saying \"No, we didn't mean those downcasts, please detect them and tell me\". Who told you, by the way, dev_compiler? ;)\r\n\r\nI also did not get any editor warnings, but when I actually ran the tests (in checked mode) I got errors.\r\n\r\n> The ElementAnnotation vs. ElementAnnotationImpl case is different: ElementAnnotation does not have an evaluationResult (the analyzer presumably will be updated such that access to evaluation results does not imply dependencies on classes named ..Impl, but it isn't there yet), so we are forced to downcast. In fact, all occurrences of ElementAnnotation in 'transformer_implementation.dart' could be changed to ElementAnnotationImpl, but in the end we would just be moving the downcast around: element.metadata has type List<ElementAnnotation> at the front end of the data flow, and we rely on getting an evaluationResult so we must have an ElementAnnotationImpl at the other end. With your change I actually get a warning at line 623, so at least the argument type in the function literal on lines 622-626 must be kept at ..Impl.\r\n\r\nGood point, updated."}}