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