Hopefully, although I grep'd and think I saw two places where there was some cheating going on.
-Alex On 11/15/13 10:27 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >Or, since that has gone the way of the dodo, I can just feed it >'this.FLEXJS_CLASS_INFO.names[0].name' ;-) > >EdB > > > >On Fri, Nov 15, 2013 at 7:12 PM, Alex Harui <aha...@adobe.com> wrote: >> Looks like it should be ok to replace with getQualifiedClassName(). >> >> -Alex >> >> On 11/15/13 9:56 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >> >>>Is there a particular reason there is a 'className' property which is >>>set on some, but not all classes and even has 'getter/setter' methods? >>> >>>Unless the property is seriously misnamed, why would you want to be >>>able to SET a class' name? If anything is constant, it should be the >>>name of the class, shouldn't it? >>> >>>It looks like a legacy thing. Would it be alright to remove it? The >>>information is now available in the metadata. >>> >>>EdB >>> >>> >>> >>>On Fri, Nov 15, 2013 at 6:12 PM, Alex Harui <aha...@adobe.com> wrote: >>>> Awesome! Definitely looked like a lot of work. Thanks for doing it. >>>> >>>> -Alex >>>> >>>> On 11/15/13 8:24 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >>>> >>>>>Big update: fixed! >>>>> >>>>>If you really want to know what needed to happen to make this work, >>>>>please read the commit messages. It wasn't a simple fix. >>>>> >>>>>Note: the metadata property is now required on each class in the >>>>>framework. I've added it to all the classes in the FlexJS framework >>>>>that are under active development. Please read the source for >>>>>examples, and I've added a small section to the wiki for reference: >>>>> >>>>>https://cwiki.apache.org/confluence/x/W5sTAg >>>>> >>>>>This was fun, but has taken way too much time, so I'll have to catch >>>>>up on my regular work in the coming week(s) ;-) >>>>> >>>>>EdB >>>>> >>>>> >>>>> >>>>>On Fri, Nov 15, 2013 at 8:55 AM, Erik de Bruin <e...@ixsoftware.nl> >>>>>wrote: >>>>>> Ah, small update: a lot of the warnings remaining in 'strict' mode >>>>>>are >>>>>> for the classes the compiler misses... That at least combines the >>>>>> issues, two birds with one stone and all ;-) >>>>>> >>>>>> EdB >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Nov 14, 2013 at 10:25 PM, Erik de Bruin <e...@ixsoftware.nl> >>>>>>wrote: >>>>>>> This may be worse than we thought... >>>>>>> >>>>>>> When I fixed the storage and retrieval of the CSS properties, it >>>>>>>still >>>>>>> didn't work properly in release mode. Some classes are found and >>>>>>> bound, others are not. Turns out that the Closure Compiler doesn't >>>>>>> resolve all dependencies accurately, the classes it misses are >>>>>>>never >>>>>>> 'considered' during compilation :-( >>>>>>> >>>>>>> I will look into the custom dependency algorithm in the Publisher >>>>>>> next. Wish me luck ;-) >>>>>>> >>>>>>> Also, the fix will literally affect all JS classes, so prepare for >>>>>>> some interesting merges. If I find a solution, I'll publish it >>>>>>>first >>>>>>> in a branch, so we can look at it together before we "commit". >>>>>>> >>>>>>> EdB >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 13, 2013 at 8:12 PM, Erik de Bruin <e...@ixsoftware.nl> >>>>>>>wrote: >>>>>>>>>>One thought is that we might store both the 'name' and the >>>>>>>>>>'qName' >>>>>>>>>>in >>>>>>>>>>the class metadata (where currently only the interfaces - if any >>>>>>>>>>- >>>>>>>>>>live) and adopt the 'getValue' routines to search that instead of >>>>>>>>>>the >>>>>>>>>>entire namespace chain. This would get rid of the need for the >>>>>>>>>>dreaded >>>>>>>>>>'__proto__' as well... >>>>>>>>> Sounds good. We need to find the superclass somehow as well. >>>>>>>> >>>>>>>> Alex, can you please create a JIRA issue for this and assign it to >>>>>>>>me. >>>>>>>> I don't think I'll have time in the next few days to work on this, >>>>>>>>and >>>>>>>> I don't want any details to get lost in the avalanche of emails on >>>>>>>>the >>>>>>>> list. >>>>>>>> >>>>>>>> EdB >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Ix Multimedia Software >>>>>>>> >>>>>>>> Jan Luykenstraat 27 >>>>>>>> 3521 VB Utrecht >>>>>>>> >>>>>>>> T. 06-51952295 >>>>>>>> I. www.ixsoftware.nl >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ix Multimedia Software >>>>>>> >>>>>>> Jan Luykenstraat 27 >>>>>>> 3521 VB Utrecht >>>>>>> >>>>>>> T. 06-51952295 >>>>>>> I. www.ixsoftware.nl >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ix Multimedia Software >>>>>> >>>>>> Jan Luykenstraat 27 >>>>>> 3521 VB Utrecht >>>>>> >>>>>> T. 06-51952295 >>>>>> I. www.ixsoftware.nl >>>>> >>>>> >>>>> >>>>>-- >>>>>Ix Multimedia Software >>>>> >>>>>Jan Luykenstraat 27 >>>>>3521 VB Utrecht >>>>> >>>>>T. 06-51952295 >>>>>I. www.ixsoftware.nl >>>> >>> >>> >>> >>>-- >>>Ix Multimedia Software >>> >>>Jan Luykenstraat 27 >>>3521 VB Utrecht >>> >>>T. 06-51952295 >>>I. www.ixsoftware.nl >> > > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl
