On Oct 18, 2016, at 7:30 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 10/18/16, 9:08 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >>> Why are you objecting to using a tooling workflow to find the potential >>> conflicts of your code against the various platform implementations? >> >> Because I don’t think it’s just a tooling problem. >> >> Basically, you are suggesting that there should be tooling to warn the >> user that certain properties or methods are not allowed because one or >> more platforms use the names. (Or rename them.) > > Yes. Unless we ensure that the API surface of every component is the same > for every platform (currently just SWF and JS), some day you will hit a > conflict. IMO it is best to have the tooling workflow catch this ASAP. > Setting up two projects in FB should work for now. Getting the FB > integration to launch both compilers so you only need one project would be > a future enhancement.
Tooling is not a bad thing, and catching problems on all platforms is a good goal, but most of the Flash problems should not exist to start with. >> >> Not allowing top specify myObj.transform (for example) because Flash uses >> transform is unintuitive and unnecessarily limiting. It also requires a >> specific tool chain for it to work. Automatically renaming properties >> seems like a hack to me and seems like it will have unexpected side >> effects. Also: there’s the question of how to you choose which >> “transform” to use in your code — the Flash one or the custom one. > > OK, I think you are describing a different problem. AIUI, you are saying > that certain APIs cannot currently be overridden or overloaded to take a > subclass or alternate type. That you can't override Sprite.transform to > take a org.apache.flexjs.Transform. I could look into getting the > compiler to accept overrides/overloads. I thought I'd done some of that > already. This is the main problem I was having. It’s not just “overriding”. The HTML side of things do not have the properties defined at all. The Flash ones have the properties, and they are used in a possibly different way than you would use them. Events are a problem that’s somewhat related to this, but not exactly. Basically, Flash is limiting how we can implement things for HTML output, and I think that’s a bad thing. > >> >>> Animations pound on x,y,width,height as does layout. >> >> So what? If there’s a specific case which is performant sensitive, the >> Flash implementation can manipulate the underlying Flash objects directly. >> >> I really believe that composition is the better solution architecturally >> (as it’s doing for the HTML side). I’d like to see some proof that >> there’s a memory usage issue with using composition, and I believe >> performance issue which might come up can be dealt with (by using SWF >> code blocks and addressing the $displayObject properties directly). > > What would be the pattern for optimization? Without tail-optimization, I > don't see how you can reduce function calls. IOW, when I set > Button.width, it will set element.width. How do you get Button.width to > directly set the Sprite's width in a COMPILE::SWF block? The underlying DisplayObjects are available for direct access in a SWF block. I expect most code which would need optimization to be in Framework code, so instead of calling Button.width, you’d call Button.$displayObject.width. Currently, $displayObject is a getter, but if that proves to be a performance problem, it could easily be converted to a simple property. Yes, you have an extra property reference (i.e. $displayObject), but I find it hard to believe that’s going to be an issue. Even if it is (i.e. in a tight loop), the DisplayObject reference can likely be cached. Does this sound reasonable? > -Alex >
