I agree. I'll try to be patient while the compiler is taught how to deal with these use cases ;-)
EdB On Mon, Sep 23, 2013 at 8:30 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 9/23/13 11:06 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >>#2: is not working with Falcon. This seems to be the only one of it's >>kind, I've not encountered this error in any of the other SDK SWCs. >> >>#3: again, if there are other instances of this pattern, this is the >>only one in which it is not working > That's nice to know, but what we don't know is how many other folks have > used these patterns in their code in whatever way is tripping up Falcon. > I would like to keep test cases around for things like this. If you can > reduce these cases to small failing unit or functional tests and set them > to 'ignore' until we get around to fixing it, that's ok with me too, if > you just want to see the framework compile cleanly. I'd rather take a bit > longer to get the framework to compile so there is a reduced chance it > will fail to compile some customer's code. > > -Alex > >> >>EdB >> >> >> >>On Mon, Sep 23, 2013 at 7:04 PM, Alex Harui <aha...@adobe.com> wrote: >>> I did find #2. I think we should look into trying to allow that. It >>> should be the same as using [] syntax. I think we allow that already. >>> >>> I also found #3. We should make sure this pattern works. I think it is >>> used quite often. >>> >>> On 9/23/13 9:46 AM, "Alex Harui" <aha...@adobe.com> wrote: >>> >>>>Can you post here or in a JIRA the latest set of errors with line >>>>numbers >>>>so I don't have to grep the source to find the code you are referencing. >>>> >>>>Thanks, >>>>-Alex >>>> >>>>On 9/23/13 7:26 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >>>> >>>>>Hi, >>>>> >>>>>I've been tweaking the code and tests a bit, and now all but the >>>>>'Spark' SDK SWCs compile. There are 3 remaining issues with the >>>>>compilation of the Spark SWC: >>>>> >>>>>1) 4 "Could not find source for class X in namespace Y" errors; no >>>>>amount of tweaking library or config paths enables me to get rid of >>>>>these... >>>>> >>>>>2) "Access of possibly undefined property embeddedFontContext through >>>>>a reference with static type IStyleClient." The property in question >>>>>is accessed via mx_internal. However, I really can't find the >>>>>mentioned property anywhere on the class or it's inheritance chain... >>>>> >>>>>3) "Implicit coercion of a value of type RemoveHandlerEvent to an >>>>>unrelated type Event." In this case, the class RemoveHandlerEvent is >>>>>defined as a [can't come up with the correct name: where you define a >>>>>second class in the same file, outside the package]. The workaround >>>>>would be to take that class definition and create it as a regular >>>>>class in the correct package... >>>>> >>>>>Thoughts? >>>>> >>>>>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
