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

Reply via email to