Hi,
I still think using common interfaces as contract for writing code would simplify things. We could have "FlexEvent" for example and base the API on this, just as an example: There could be a "FlashFlexEvent" which extends FlexEvent with things specific to Flash and a JSFlexEvent that has things specific to JavaScript. I still don't see how this would be a performance thing to code against FlexEvent in general and cast in case some platform specialities are needed. Isn't JavaScript typeless? I think on the JS side there shouldn't be any casts needed to access the JS specific parts. Does anyone claiming that this could be a performance problem have any proof for this performance degradation? If yes, I would be happy to review that (never stop learning). Chris ________________________________ Von: Harbs <harbs.li...@gmail.com> Gesendet: Montag, 11. Juli 2016 08:59:16 An: dev@flex.apache.org Betreff: Re: [FlexJS] subclassed Flash classes and casting One simple example is clone() on on both Point and Rectangle. Flash returns a flash Rectangle, but Flex is expecting a flex Rectangle. Another one that I ran into in my own code is union() in Rectangle. The casting that I did, did not even work. The compiler does not complain if you change the return type to a subclass, but it looks like I’m getting runtime errors. On Jul 11, 2016, at 8:50 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 7/10/16, 10:37 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> I believe the reason it’s subclassing flash.geom.Rectangle is because >> some Flash classes return Rectangles and those cases need to be handled. >> >> I’m not sure how the static methods would work and resolving to flash >> packages should only happen on the SWF side. > > I think if no Flash APIs are directly exposed to the SWC's APIs and vice > versa, then the code in the SWC would convert/proxy/marshall between the > two Rectangles. > > Do you know where some problem places are in the code? It might help to > examine concrete examples. > > -Alex >
