Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))

[Alex Harui]

OK, I think I got this working and pushed it to the JsToAs branch of
Falcon.

I’m going to take on allowing keywords to be used for function names and
some other places as I noticed it is affecting the JS to AS port as well.

-Alex

On 9/19/15, 1:57 PM, "Josh Tynjala"  wrote:

>Yeah, changing FalconJX to handle window as a special case would work too.
>It would make things easier on other tools, like externc and dts2as. As a
>bonus, while it's a simple string that we wanted to avoid, it's actually
>valid JS, so it wouldn't have as much potential for conflict. I think I
>like this idea.
>
>In regards to putting variables/properties in packages, it's possible in
>AS3. In Feathers, I created a feathers.FEATHERS_VERSION constant a while
>back. While I used const there, I assume that var would be valid too.
>
>package feathers
>{
>public const FEATHERS_VERSION:String = "2.2.0";
>}
>
>https://github.com/BowlerHatLLC/feathers/blob/v2.2.0/source/feathers/FEATH
>ERS_VERSION.as
>
>It even shows up in the API documentation:
>
>http://feathersui.com/api-reference/feathers/package-detail.html
>
>I suspect that getters and setters might not work in a package, though.
>
>- Josh
>
>On Sat, Sep 19, 2015 at 1:36 PM, Alex Harui  wrote:
>
>> Inline as well, gotta scroll way down for my latest proposal.
>>
>> On 9/19/15, 9:01 AM, "Josh Tynjala"  wrote:
>>
>> >Responses inline.
>> >
>> >- Josh
>> >
>> >On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui  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 

Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))

[Alex Harui]

Inline as well, gotta scroll way down for my latest proposal.

On 9/19/15, 9:01 AM, "Josh Tynjala"  wrote:

>Responses inline.
>
>- Josh
>
>On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui  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 

Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))

[Josh Tynjala]

Yeah, changing FalconJX to handle window as a special case would work too.
It would make things easier on other tools, like externc and dts2as. As a
bonus, while it's a simple string that we wanted to avoid, it's actually
valid JS, so it wouldn't have as much potential for conflict. I think I
like this idea.

In regards to putting variables/properties in packages, it's possible in
AS3. In Feathers, I created a feathers.FEATHERS_VERSION constant a while
back. While I used const there, I assume that var would be valid too.

package feathers
{
public const FEATHERS_VERSION:String = "2.2.0";
}

https://github.com/BowlerHatLLC/feathers/blob/v2.2.0/source/feathers/FEATHERS_VERSION.as

It even shows up in the API documentation:

http://feathersui.com/api-reference/feathers/package-detail.html

I suspect that getters and setters might not work in a package, though.

- Josh

On Sat, Sep 19, 2015 at 1:36 PM, Alex Harui  wrote:

> Inline as well, gotta scroll way down for my latest proposal.
>
> On 9/19/15, 9:01 AM, "Josh Tynjala"  wrote:
>
> >Responses inline.
> >
> >- Josh
> >
> >On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui  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 

Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))

[Alex Harui]

On 9/19/15, 7:43 AM, "Josh Tynjala"  wrote:

>I think that making it possible to reference a class in the global
>package,
>even when another class with the same name is imported, is a good
>improvement. Probably easiest to implement.
>
>Along the same lines as an unimport, what if we could do something like
>this to remove ambiguity:
>
>import GoogEvent = goog.events.Event;
>
>TypeScript supports this kind of import, and it's very useful for removing
>ambiguity. I really wish AS3 had it. It would have made importing both
>Flash events and Starling events so much easier.

Hmm.  Maybe, but what does that sort of import really do?  Why not just
create a global subclass of goog.events.Event?


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.

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?

-Alex

Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))

[Josh Tynjala]

I think that making it possible to reference a class in the global package,
even when another class with the same name is imported, is a good
improvement. Probably easiest to implement.

Along the same lines as an unimport, what if we could do something like
this to remove ambiguity:

import GoogEvent = goog.events.Event;

TypeScript supports this kind of import, and it's very useful for removing
ambiguity. I really wish AS3 had it. It would have made importing both
Flash events and Starling events so much easier.

- Josh
On Sep 18, 2015 10:28 PM, "Alex Harui"  wrote:

> I’m still digging into the compiler, but I had some new thoughts:
>
> What if you only got an ambiguous definition error if you had two classes
> neither of which is in the global package and didn’t qualify its usage?
> This might be easiest to implement.  If we did that, then:
>
> Scenario 1:
> import flash.events.Event;
> import org.apache.flex.events.Event;
>
> var foo:Event; // ambiguous definition error
>
>
> Scenario 2 (using js.swc):
> import goog.events.Event;
>
> var foo:Event;  // always uses global package Event
> var bar:Event = new goog.events.Event(); // error since bar is global
> Event type
> Var baz:Event = new Event(); // no error but instantiates global Event
>
> This would mean that, for folks using js.swc, you couldn’t just import
> some class in a package that conflicts with a global package class and use
> it without fully qualifying it.
>
> We could add a config option to warn instead of error on use of global
> package classes.
>
> Even crazier, we could add an “unimport” directive or some compiler
> option, asdoc tag, or metadata that does the same and tells the compiler
> to never resolve to the global package.
>
> Thoughts?
> -Alex
>
> On 9/18/15, 12:09 PM, "Alex Harui"  wrote:
>
> >
> >
> >On 9/18/15, 11:54 AM, "Josh Tynjala"  wrote:
> >
> >>Of the options that you presented, I think I like  *.Event and .Event the
> >>most.
> >>
> >>The options with :: don't feel quite right. While I know that packages
> >>are
> >>namespaces (I remember making that discovery back in the day and
> >>excitedly
> >>blogging about it), other classes aren't usually referenced with :: in
> >>code. With that in mind, I like . better than :: because the . is more
> >>consistent. If it were somehow easier to implement, though, I could live
> >>with it.
> >>
> >>A simple string like global or null might conflict with some top-level
> >>variable in user code or in the standard library of some JS environment,
> >>so
> >>I think that style should be avoided.
> >
> >Agreed.
> >
> >>
> >>Of the two between *.Event and .Event, I'm not quite sure which I like
> >>better. Which of these seems more readable?
> >>
> >>var myVar:.Event = new .Event();
> >>
> >>var myVar:*.Event = new *.Event();
> >>
> >>At first, I thought I liked *.Event better, but I might be preferring
> >>.Event more now.
> >
> >Yeah, it might be easier grammar-wise to have something in front of the
> >‘.’.  I’m still digging into the compiler.  I will report my findings and
> >recommendations before committing anything.
> >
> >-Alex
> >
>
>

Re: Ambiguous Definitions (was Re: [FlexJS] Framework using externs (was: Setup Error))

[Josh Tynjala]

Responses inline.

- Josh

On Sat, Sep 19, 2015 at 8:03 AM, Alex Harui  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".


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

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.