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