On 8/18/16, 3:40 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >On Aug 19, 2016, at 12:49 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 8/18/16, 2:15 PM, "Harbs" <harbs.li...@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
