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