Closed dam0vm3nt closed 8 years ago
I realize only now that probably this should be a reflectable
issue more than a polymer-dart
one...
There is an issue at https://github.com/dart-lang/reflectable/issues/48 about this bug now. Copy/paste from the code quoted above produces text containing some <span>..</span>
tokens, but after I removed that it seems likely that there is only one problem: A mixin application (whose "name" is on the format A with M
) is used in an is!
test, which is of course not syntactically correct. That problem is being addressed in relation to https://github.com/dart-lang/reflectable/issues/48.
You can do git clone 'https://github.com/dart-lang/reflectable.git'
now and put something like
dependencies:
reflectable:
path: ../the/path/to/reflectable
into your 'pubspec.yaml', and try it out with the version of reflectable that contains a fix for the code generation bug (0f06199f91c49601ba1133a0a8f42cd0faa0d4b9).
ok now it works. tnx.
@eernstg I'm getting
web\main.dart:56:23403:
Cannot resolve 'field'.
Doesn't seem to like this area
const <Object>[const prefix32.field('created_at')]
That's an annotation on one of my models. So not sure what it's doing there.
Sounds like a new issue, could you please report it as an issue on https://github.com/dart-lang/reflectable/issues?
The fact that it is an annotation on one of your models could mean that it is there because there is a reflector which covers that class and includes a metadataCapability
. In that case it should be possible to perform a myClassMirorr.metadata
query, and it should return the list you mentioned. But maybe it fails because something is wrong in the computation of prefix32
.
I think this is resolved now, please re-open if that is not the case
This is a prosecution of #651 . Using generics on mixin makes
reflectable
mess the generated wrapper code.For example with:
building you get :
but the real problem is that the generated code will contains something that is messed up:
Notably :
And: