flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] HTMLElementWrapper extending Sprite
Date Thu, 18 Aug 2016 23:22:12 GMT


On 8/18/16, 3:40 PM, "Harbs" <harbs.lists@gmail.com> wrote:

>
>On Aug 19, 2016, at 12:49 AM, Alex Harui <aharui@adobe.com> wrote:
>
>> 
>> 
>> On 8/18/16, 2:15 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>> 
>>> Like I mentioned in the other thread, it’s NOT just an author-time
>>> problem.
>>> 
>>> Conflicts in variables and methods will cause Flash runtime errors and
>>> override can often not be done properly.
>> 
>> Are you saying the override would have an incompatible signature with
>>the
>> Flash API?  What are some examples that you ran into?  Especially ones
>> where if the compiler warned you and recommended that you pick a new
>>name
>> that it would seriously harm usability.
>
>I don’t remember off-hand which ones I ran into, but it definitely was an
>issue. I can try to go through the code commits and see if I can find
>examples. We can’t hide the Flash APIs and then require the client
>specifies compatible overrides. That defeats the whole point of hiding
>the APIs.

It occurs to me that even on the JS side there is a risk that a property
or method name you choose will already be taken by some internal aspect of
the platform-specific implementation that we probably would filter from
the "public" API.  I think it would be too constraining declare a set of
APIs by which all platform implementations must conform.  Because there
are more small separate pieces in the FlexJS implementation, there must be
public APIs used to communicate between those pieces that most application
developers will not need to know about.  The best FlexJS IDEs will allow
you to filter those out.  And then you might still run into a conflict
because the actual platform implementation chose a particular public name
for something.  I'm interested to see how often that is going to happen.

In the longer term, I still hope to support simple forms of overloading by
decorating names like C++ did on Windows, so renaming methods doesn't seem
that terrible to me.

My 2 cents,
-Alex

Mime
View raw message