flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))
Date Sat, 19 Sep 2015 20:36:15 GMT
Inline as well, gotta scroll way down for my latest proposal.

On 9/19/15, 9:01 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:

>Responses inline.
>
>- Josh
>
>On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui <aharui@adobe.com> wrote:
>
>>
>> Hmm.  Maybe, but what does that sort of import really do?  Why not just
>> create a global subclass of goog.events.Event?
>>
>
>A global subclass would work only if you were creating all instances. If
>you need to use the class as a method argument, where the arguments come
>from somewhere else that might not be using the subclass, the global
>subclass would not work:
>
>private function listener(event:GoogEvent):void //runtime error because it
>might receive goog.events.Event
>
>If what imports do is say, "every time that you find Event, replace it
>with
>goog.events.Event", then this new syntax would allow a little more
>flexibility "every time that you find GoogEvent, replace it with
>goog.events.Event".

Well, that would be a big and scary change.  For some reason I don’t know,
imports open namespaces for multi name lookups at runtime.

What’s interesting about the TS import is it puts you on the slippery
slope towards preprocessor macros.

>
>
>> BTW, I realized that the choices should have had more examples.  Maybe:
>>
>>   var foo:.Event;
>>
>> doesn’t looks so bad, but once you fill it out further:
>>
>>   var foo:.Event = new .Event();
>>   var bar:.Event = foo as .Event();
>>   var baz:.Event = .Event(foo);
>>
>> Do we still like it?  I think I have found one place to try to change to
>> make it work.
>>
>
>If the global Event can be used without any qualifier, this wouldn't be
>necessary. However, yes, I think I still like it the same. I would say
>that
>the most difficult thing to read is the colon followed by the dot (:.),
>but
>that was in the original example
>
>Another option is to throw in some double underscores to try to avoid
>naming conflicts:
>
>__global__.Event
>
>I think I'd still prefer .Event, though.
>
>
>> However, my new thought of the day is this:
>>
>> For SWFs, we can discourage folks from making conflicts with classes in
>> the “global” package so this is really for JS users.  But don’t folks
>> doing native JS already have the option of using “window” as the package
>> name?
>>
>>   import window.Event;
>>   var foo:window.Event = new window.Event();
>>
>> Could we auto-replace Event with window.Event when generating externs
>>and
>> then require folks to use window.Event when they want the “global” ones?
>>
>
>I had never considered window to be like a package before. That's a very
>interesting idea.
>
>It's worth noting that window has its own member variables too, so it's
>not
>only classes that are stored there. Will there be a conflict if both a
>window global variable and a window package exist? I guess, since AS3
>supports variables and functions inside a package, window wouldn't
>necessarily need to be a global variable. We could just move everything
>into the package.

Actually, we’ve already hit this trying to stub GCL for FlexJS.  GCL has
functions and variables on goog.events like goog.events.fireListener, and
then classes like goog.events.EventTarget.  I don’t recall any AS
variables/properties on packages in AS3 because I think packages are not
objects in AS3 like they are in JS.  So we created a class in the goog
package called events (lower case) and put the same variables GCL puts on
its JS goog.events object.  One of my latest commits changes the compiler
to try goog.events as both a package and a class.

So yes, in theory we would have a class in the default package called
“window” but also classes in the “window” package called Events.

>
>externc would need to be updated with a new optional argument to say that
>globals should be put into a package. I think that this package name
>should
>be configurable, to support other hypothetical JS environments.

Well, that’s true if we do it the “legitimate” way.  But that might also
force everyone using js.swc to start every file with “import windows.*”
which is acceptable to me, but let me describe a possible “hack”.

I think we could make “window” a special word in FalconJX and when
creating package namespaces, collapse it down to “” (empty string) which
is equivalent to the default package.  Then, if you are just writing plain
JS and don’t import any other class called Event, you can just use Event
without any import statement or package prefix and it would just work.  No
changes to ExternC or any existing code.

Then, if you import an Event class like goog.events.Event, the
AmbiguousDefinition logic would look at the file scope to see if there was
an “import window.Event;”.  If there isn't, it will assume you meant
goog.events.Event because not importing window.Event would mean you never
intended to use the class in the default package.

It would be only in the rare case where you import both goog.events.Event
and window.Event that you would start getting AmbiguousDefinition errors
and have to fully qualify the plain Event as window.Event, and the output
would not be prefixed with “window”.

And what I like more about this sort of hack (or doing it the legitimate
way) is that it doesn’t introduce new “unexpected” syntax like “.Event”.

Thoughts?
-Alex

Mime
View raw message