flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Getting ready for the refactor-sprite merge (was Re: [FlexJS] HTMLElementWrapper extending Sprite)
Date Thu, 27 Oct 2016 16:01:22 GMT


On 10/27/16, 12:15 AM, "Harbs" <harbs.lists@gmail.com> wrote:

>I had an idea last night:
>
>Instead of having two different namespaces for wrapped and unwrapped
>components, what about making it a compiler option?

Actually, it appears that we can have two SWCs with the same namespaces.
The most recently compiled one will win unless we start specifying each
SWC in flex-config.xml.  Currently we only specify a folder so all SWCs
are considered.  IMO, specifying a folder makes life easier for IDE and
Ant users and I can manage working with a list of specific SWCs.

>
>The primary difference between the two is:
>1. The base class is different.
>2. References in platform-specific code to the platform-specific
>implementation when needed.
>
>#1 can be resolved by conditional compilation blocks (such as
>COMPILE::OPTIMIZE_PERFORMANCE and COMPILE::OPTIMIZE_COMPATIBILITY)

Maybe, but I would think that would make the source code hard to read with
so many options.

>#2 can be resolved by having a variable which points to the
>implementation (and typed as an Object) So for wrapped components,
>myComponents.impl (or whatever we’d call it) would be
>HTMLElementWrapper.$displayObject and for subclassed components it would
>be “this”. For HTML, it would be element, etc.

I want the existing code in Basic to work with out an additional
variables.  IMO, that's the only way to know if we have an issue from the
subclassing that the compiler can't solve.  But where the wrapping leaked
into other SWCS like Chart and Graphics, I'm thinking of adding the
$displayObject variable in the Basic UIBase so we don't have to duplicate
the other SWCs as well.

-Alex

Mime
View raw message