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. > >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. > >> 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? -Alex
