-
Notifications
You must be signed in to change notification settings - Fork 33
No more working with reflectable
version 0.3.4
#651
Comments
Reflectable 0.3.4 supports many things associated with genericity (whereas 0.3.3 just did a few things to avoid crashing when encountering a generic type), so the general situation should be much better. However, one thing that 0.3.3 couldn't, 0.3.4 can't, and no upcoming version of reflectable is expected to be able to do for a while is to return the actual type arguments of an instantiation of a generic class, also known as a parameterized type (e.g., List is an instantiation of List): The actual type arguments are not not statically known in general, and there is no primitive at runtime (except for built-in reflection) providing access to actual type arguments. E.g., if we have the In order to implement Generic classes do_not_have a reflected type, which is by the way also the response you'll get from 'dart:mirrors', so Unfortunately, these two issues sometimes conspire to make mirrors of instantiations of generic classes (e.g., a mirror of Say, your program might have a method with an argument of type This could very well be the situation that you have encountered: The program is asking for the The first step in fixing this problem could be to ask If you wish to check things like "is the object In 0.3.3 you could get away with it: The generic class But it might be helpful to add an We might also add a method Another possibility is that Polymer only needs to cover a fixed set of classes, in which case the |
So, not using generic type arguments would be a workaround? |
It may not be enough. If it just means using |
(EDITED) This test case is failing even though the annotated field is of plain I think there are use cases (like Also using generics is a good practice and that means that |
Also I don't fully agree on the opinion that returning After all I can always call method like say |
@eernstg The behavior is also now inconsistent, the mirrors implementation will still return |
I have also confirmed that in regular import 'dart:mirrors';
main() {
List<String> foo = [];
print(reflect(foo).type.reflectedType); // Prints `List`
print(reflectClass(Foo).declarations[#bar].type.reflectedType); // Prints `List<String>`
}
class Foo {
List<String> bar;
} |
I've experimented with |
Added a version constraint and released a new version to alleviate the problem for now. This can be removed once we figure out a workaround. |
Good! Btw. |
Yes, I think that will fix the issue as well |
There is a |
https://github.com/dart-lang/reflectable commit 10da7e398ce439314dacfb276e2a58ecbabce5b4 contains |
Reflectable 0.4.0 has been published, containing the above-mentioned CL as well as another one that changes the implementation to share multiple occurrences of the same type expression (which reduces the size of the source code). It also adds I suspect that you may be able to simply change The tricky point is that If you focus on transformed code, though, the scope of We gave this version a new major number because |
Great, I can work on updating Polymer soon. In terms of the accidental breaking change in 0.3.4, usually the process would be to just release a new version (0.3.5, or 0.3.4+1) which reverts back to 0.3.3. |
It would be most useful if we were to create a new version 0.3.5-or-so which includes all the fixes in 0.3.4 and just makes |
Yes, that would be the ideal. It is probably only worth doing if you are getting non-polymer users who ran into this issue though. Mostly I just wanted to highlight that as the normal procedure for this sort of thing :) |
Right, I think I'll leave it as it is. There is an inconsistency lurking in the dark, but we did after all consider the changes from 0.3.3 to 0.3.4 to be bug fixes and implementations of missing features, including the behavior of |
Sure, but a even a bug fix is a breaking change if it changes behavior :). I just don't think that it is worth fixing it unless its causing an issue. Polymer has already released a new version which works with 0.4.0, so if nobody else is filing issues you are probably ok. |
Done deal. ;) |
@eernstg I think I found another case where 0.3.4 or later breaks stuff that was working in 0.3.3. If you have a behavior that's generic then it will fail to compile it. abstract class FooBehavior<T> {
...
}
class FooElement extends PolymerElement with FooBehavior<MyModel> {
...
} |
This could very well be an issue with Polymer itself as well, I need to add some tests around this type of thing. |
It was working with 1.0.0-rc.6 and reflectable 0.3.3. This sounded similarish. More than happy to open a new issue. |
@jakemac53 I had a similar problem (see conversation on slack) and I don't think the problem is in polymer. Infact if you look at what is generated by the For example there are things like : |
I was specifically getting whenever using a generic mixin there. web\main.dart:29:7:
A final variable must be initialized.
Try adding an initializer or removing the 'final' modifier. |
@donny-dont look at the whole output you should see the messed up generated code. |
Clearly reflectable should not generate |
You can do
into your 'pubspec.yaml', and try it out with the version of reflectable that contains a fix for the code generation bug (0f06199f91c49601ba1133a0a8f42cd0faa0d4b9). |
roger. |
ok now it works. tnx. |
and BTW : seams also a lot faster ... maybe a suggestion. |
Cool! I'm not sure why it might be faster, though. |
Since
reflectable
version0.3.4
annotating properties of typeList
with@property
leads to the following exception :For example with :
and dart :
while forcing to version
0.3.3
make it work again.The text was updated successfully, but these errors were encountered: