> 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.) 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. > 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). On Oct 18, 2016, at 6:33 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 10/18/16, 8:18 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> I’m not sure where this response went… >> >> On Sep 29, 2016, at 9:15 AM, Harbs <harbs.li...@gmail.com> wrote: >> >>> Let’s actually do some profiling so we can see if there’s really an >>> issue. >>> >>> Is there really a difference whether you have one object whose size is >>> x+y or two objects where one size is x and another is y? >>> >>> I doubt there’s anywhere close to twice as many function calls. Yes. >>> For setting native Flash properties there will be double setters and >>> getters, but that’s not going to be the majority of the code being run >>> and we might be able to optimize those calls in certain cases if it’s an >>> issue. > > Why are you objecting to using a tooling workflow to find the potential > conflicts of your code against the various platform implementations? > There is a separate discussion of being able to compile against both > platforms from a single IDE project. IMO, that would be best because > there can be other platform-specific things not related to the wrapping > that can conflict against your code. > > Again, the "oh, it's just a little bit of extra code" is what cause Flex > to have a 13,000 line UIComponent and a 130K hello world. Please let us > use the tool chain to find the conflicts and not burden the production > code. Animations pound on x,y,width,height as does layout. > > Thanks, > -Alex
