On 10/20/16, 1:48 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>AFAIK, properties cannot be overridden as getters and setters, so even >simple properties can have issues. Yes. Rect Point and Matrix were all >classes which caused problems. This is true for now, but this is what I want to look into a bit more. The discussion on language features and adding generics will eventually become a discussion about allowing overloading since TS and other languages have it. I think I've already tweaked the compiler to allow it for JS output. The problem is that the SWF code can't generate a true override because the Flash Runtime verifier won't allow it. But I think that the compiler might be able to actually use the base class type in the output code and as long as the override is an extension of that type it could work. IOW, if you Sprite has: function get mask():flash.geom.Rect; And class flex.geom.rect extends flash.geom.Rect; Then if in UIBase: override function get mask():flex.geom.Rect would be allowed by the compiler but it would generate override function get mask():flash.geom.Rect The code inside might still do: return new flex.geom.Rect(); but that would be ok since it is a subclass of flash.geom.Rect. >> Maybe the right answer is to take your sprite-wrapping and just make >>another component set in parallel to the basic set. > >This makes sense to me. I’m fine with having another “optimized” >component set if that proves to make a difference in performance, but I >think most folks migrating code will want to use “wrapped” components to >allow the easiest migration. Think of it this way: if AS did allow certain kinds of overloading, would you have used that instead of wrapping? If so, let me see about allowing limited overloading before we head down the path of wrapping in another component set. At some point, folks will aggregate often-used styles and bead properties to the API surface and we'll have a conflict anyway. But either way, a set of components that have more of the MX/Spark APIs but no guarantee of the underlying infrastructure is definitely something I wanted to see created. Looks like it was helpful for you. The goal of the basic set, however, is to deliver the smallest, close-to-native-for-that-platform output so folks who look at the generated code don't say "Hmm, look at all that overhead, I should just write it direct in JS or Flash". I think the examples we have prove that you can produce a runnable application without the overhead of wrapping the SWF side. But if there are advantages to wrapping the SWF side because it is the best way to ease migration that's a legitimate design decision for a different set of components. Thanks, -Alex
