JS Isolation/Namespace

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

JS Isolation/Namespace

Nicolas Cannasse
Hi list,

I'm thinking about removing --js-namespace and replacing with with
another flag that will ensure that the JS code does not pollute the
global namespace.

First step has been done by integrating Philippe patch which adds "var"
everywhere needed, the isolation flag will simply add the following code
around the generated JS :

(function(){ .... })();

This will be the default behavior in order to keep backward compatibility.

Now what about the flag name, it should be --js-something, any idea ?

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Elsass Philippe
Such "isolation" is important and it should be the default imho, and be more lik having --js-global-scope to litter the global scope as it does now.

I'm not sure how Remoting works here, but like Type.resolveClass which sadly uses eval() I think the solution could be to keep a map of all classes - I think the 'context' suggestion is correct:

(function(context) {
...
context.hxClasses = {};
context.hxClasses["com.foo.Bar"] = com.foo.Bar;
})(this);

BTW if we're using this isolated scope, then the generator doesn't need to generate all these -if (typeof(com) == "undefined")- tests.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re:[haXe] Re: JS Isolation/Namespace

Skial Bainn

I agree with Elsass that the code should be isolated as much as possible, but having an option to litter the global scope could be solved with the self executing function, possibly by assigning them to the context, or by creating a Global object on the haxe object.

(function(context){

var haxe = {};

haxe.Global = {};

...

context.haxe = haxe;

})(window);

So then we could litter that Global object instead. Also some rewriting of the js std library would need to be done for this to work.

Because some features of haxe need to be in the global scope, like the flash<->js remoting, you could possibly just add the haxe object to the context, and everything else, all other packages, exists in the self executed function scope which should be fine.

Also I think the hxClasses could be kept private by not adding it to the context, as anything defined in the self executing function can still access it. I haven't looked at how Type works, so I might have gotten things wrong.

On Oct 15, 2011 12:04 PM, "Elsass Philippe" <[hidden email]> wrote:
Such "isolation" is important and it should be the default imho, and be more lik having --js-global-scope to litter the global scope as it does now.

I'm not sure how Remoting works here, but like Type.resolveClass which sadly uses eval() I think the solution could be to keep a map of all classes - I think the 'context' suggestion is correct:

(function(context) {
...
context.hxClasses = {};
context.hxClasses["com.foo.Bar"] = com.foo.Bar;
})(this);

BTW if we're using this isolated scope, then the generator doesn't need to generate all these -if (typeof(com) == "undefined")- tests.

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Juraj Kirchheim
Hiho,

I've given a bit of thought to this discussion, and more generally to
the JS output of haXe. I agree there should both be an option to not
litter the global namespace as well as putting everything in there.
Also, while looking at things, I found there's quite a bit of
redundancies in the output and playing around a little I came up with
this: https://gist.github.com/1291347

It adds a little overhead (65 lines), but reduces the actual generated
code to something like this:

        (new $package([], null, ctx))
                .makeEnum("ValueType", "TNull", "TInt", "TFloat", "TBool",
"TObject", "TFunction", $c("TClass", 1), $c("TEnum", 1), "TUnknown")
                .makeClass("List", null, {
                        h: null,
                        q: null,
                        length: 0,
                        add: function(item) {
                                var x = [item];
                                if(this.h == null) this.h = x; else this.q[1] = x;
                                this.q = x;
                                this.length++;
                        }
                        /* ... */
                })
                .child('haxe')
                        .makeClass('Public')
                        .child('rtti')
                                .makeClass('Generic')
                        .close()
                        .child('unit')
                                .makeClass('TestCase' /* ... */)
                                .makeClass('TestResult' /* ... */)
                                .makeClass('TestRunner', function (p) {
                                        if (p === $skip) return;
                                        this.result = new ctx.haxe.unit.TestResult();
                                        this.cases = new ctx.List();
                                }, { /* ... */ })
                        .close()
                .close()
                /* ... */
        .close()

This is a lot terser and actually almost directly usable for JS devs.
Also it won't overwrite any existing things, so it's well suited for
loading two complementary (but not quite disjunctive) haXe outputs
into the same "context".

Any thoughts on that?

greetz
back2dos

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Elsass Philippe
In reply to this post by Nicolas Cannasse
@back2dos
Your generation suggestion is kind of radical :)

As a JS coder I'd say the result is very alien... but it's certainly interesting.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Cauê W.
@back2dos, that's a very nice output! So clean!
@Elsass there are some js libraries that use this kind of construct, out of the top of my head there's http://qooxdoo.org/ 

2011/10/16 Elsass Philippe <[hidden email]>
@back2dos
Your generation suggestion is kind of radical :)

As a JS coder I'd say the result is very alien... but it's certainly interesting.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

singmajesty
Since haxe is compiling the code, we don't need to worry about  
ease-of-use. I personally vote for a line by line "mirror image" of your  
original code, using standard functions, prototypes and constructors  
rather than classes. This makes it simple to debug your code and translate  
mentally from your haxe code to the generated Javascript output.

There are at least three uses for Javascript:

  1.) A single web application

  2.) One of multiple applications on the same page

  3.) A "dash" of functionality

Pursuing ways to better encapsulate code, and finding ways to minimize the  
standard output to even less bootstrap code, would help improve scenarios  
2 and 3.

The format back2dos suggested is cool -- perhaps as a macro people could  
download? A format like that, I think, makes a little more sense with a  
user-facing API than for code conversion


On Sun, 16 Oct 2011 14:57:07 -0700, Cauê Waneck <[hidden email]> wrote:

> @back2dos, that's a very nice output! So clean!
> @Elsass there are some js libraries that use this kind of construct, out  
> of
> the top of my head there's http://qooxdoo.org/
>
> 2011/10/16 Elsass Philippe <[hidden email]>
>
>> @back2dos
>> Your generation suggestion is kind of radical :)
>>
>> As a JS coder I'd say the result is very alien... but it's certainly
>> interesting.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Bruno Garcia-2
In reply to this post by Elsass Philippe
On 10/15/2011 04:02 AM, Elsass Philippe wrote:
> I'm not sure how Remoting works here, but like Type.resolveClass which
> sadly uses eval() I think the solution could be to keep a map of all
> classes - I think the 'context' suggestion is correct:
>
> (function(context) {
> ...
> context.hxClasses = {};
> context.hxClasses["com.foo.Bar"] = com.foo.Bar;
> })(this);

Agreed! Please also see this issue:
http://code.google.com/p/haxe/issues/detail?id=544

The nice bonus about a hxClasses mapping is that Google's JSCompiler can
flatten all references of com.foo.Bar into simple local variables. This
isn't possible now because Type relies on eval for lookups.

Bruno

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Juraj Kirchheim
In reply to this post by Elsass Philippe
Well it's kind of a cross-breed between jQuery chaing and
Ext.js/qooxdoo class declaration "syntax" with a mechanism for haXe
enums on top :D

On Sun, Oct 16, 2011 at 11:43 PM, Elsass Philippe
<[hidden email]> wrote:
> @back2dos
> Your generation suggestion is kind of radical :)
> As a JS coder I'd say the result is very alien... but it's certainly
> interesting.
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Nicolas Cannasse
In reply to this post by Juraj Kirchheim
Le 16/10/2011 22:55, Juraj Kirchheim a écrit :

> Hiho,
>
> I've given a bit of thought to this discussion, and more generally to
> the JS output of haXe. I agree there should both be an option to not
> litter the global namespace as well as putting everything in there.
> Also, while looking at things, I found there's quite a bit of
> redundancies in the output and playing around a little I came up with
> this: https://gist.github.com/1291347
>
> It adds a little overhead (65 lines), but reduces the actual generated
> code to something like this:

IMHO the default JS output should look much more like hand-written JS.

But since I know there is (at least) as many nice output as there is
haXe/JS developers, then you can write your own custom JS generator in
haXe thanks to macros.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Juraj Kirchheim
> IMHO the default JS output should look much more like hand-written JS.
>
> But since I know there is (at least) as many nice output as there is haXe/JS
> developers, then you can write your own custom JS generator in haXe thanks
> to macros.
>
> Nicolas

Yes, I will try that. It's probably better to compare two working
solutions, then to hypothesize ;)

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Michiel Crefcoeur
In reply to this post by Nicolas Cannasse

I agree that the default JS output should be a verbose reference output to test against for custom generated JS.
The one thing that needs to be addressed is to make all functions (mainly deserialization) not depend on whether or not classes/namespaces will be accessible from global scope at runtime.
There are many JS targets out there that all have their own specifics.
I have been using the JS target extensively over the past few years, first using a postcompiler to address all aforementioned issues and once available, translated it all to macro's.
I'd be more than happy to contribute and share some thoughts about making haXe the ideal language for targeting JS.

Cheers,
Michiel

2011/10/17 Nicolas Cannasse <[hidden email]>
Le 16/10/2011 22:55, Juraj Kirchheim a écrit :

Hiho,

I've given a bit of thought to this discussion, and more generally to
the JS output of haXe. I agree there should both be an option to not
litter the global namespace as well as putting everything in there.
Also, while looking at things, I found there's quite a bit of
redundancies in the output and playing around a little I came up with
this: https://gist.github.com/1291347

It adds a little overhead (65 lines), but reduces the actual generated
code to something like this:

IMHO the default JS output should look much more like hand-written JS.

But since I know there is (at least) as many nice output as there is haXe/JS developers, then you can write your own custom JS generator in haXe thanks to macros.

Nicolas


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Skial Bainn
I've made some changes to the js output and submitted it for review at http://code.google.com/p/haxe/issues/detail?id=554

I still need to do more tests to make sure everything works correctly, but from compiling some of my haxe js projects, things seem to be working ok - but this doesn't mean I haven't screwed something up :P

Cheers
Skial

On Mon, Oct 17, 2011 at 10:31 AM, Michiel Crefcoeur <[hidden email]> wrote:

I agree that the default JS output should be a verbose reference output to test against for custom generated JS.
The one thing that needs to be addressed is to make all functions (mainly deserialization) not depend on whether or not classes/namespaces will be accessible from global scope at runtime.
There are many JS targets out there that all have their own specifics.
I have been using the JS target extensively over the past few years, first using a postcompiler to address all aforementioned issues and once available, translated it all to macro's.
I'd be more than happy to contribute and share some thoughts about making haXe the ideal language for targeting JS.

Cheers,
Michiel


2011/10/17 Nicolas Cannasse <[hidden email]>
Le 16/10/2011 22:55, Juraj Kirchheim a écrit :

Hiho,

I've given a bit of thought to this discussion, and more generally to
the JS output of haXe. I agree there should both be an option to not
litter the global namespace as well as putting everything in there.
Also, while looking at things, I found there's quite a bit of
redundancies in the output and playing around a little I came up with
this: https://gist.github.com/1291347

It adds a little overhead (65 lines), but reduces the actual generated
code to something like this:

IMHO the default JS output should look much more like hand-written JS.

But since I know there is (at least) as many nice output as there is haXe/JS developers, then you can write your own custom JS generator in haXe thanks to macros.

Nicolas


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Skial



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: JS Isolation/Namespace

Michiel Crefcoeur
These output modifications can also be accomplished using a JS generator macro.
Using this generator, each class has its own execution context that only has access to the types required by the class itself. It introduces only one global variable: jstm.
Some websites that use JSTM generated code: (sorry, all Dutch :-) )
http://hollander.nl/
Open up your browser dev tool and look at the JS requests.

No support yet for haXe 2.08 as I've been way to busy lately.

Cheers,
Michiel

2011/10/19 Skial Bainn <[hidden email]>
I've made some changes to the js output and submitted it for review at http://code.google.com/p/haxe/issues/detail?id=554

I still need to do more tests to make sure everything works correctly, but from compiling some of my haxe js projects, things seem to be working ok - but this doesn't mean I haven't screwed something up :P

Cheers
Skial

On Mon, Oct 17, 2011 at 10:31 AM, Michiel Crefcoeur <[hidden email]> wrote:

I agree that the default JS output should be a verbose reference output to test against for custom generated JS.
The one thing that needs to be addressed is to make all functions (mainly deserialization) not depend on whether or not classes/namespaces will be accessible from global scope at runtime.
There are many JS targets out there that all have their own specifics.
I have been using the JS target extensively over the past few years, first using a postcompiler to address all aforementioned issues and once available, translated it all to macro's.
I'd be more than happy to contribute and share some thoughts about making haXe the ideal language for targeting JS.

Cheers,
Michiel


2011/10/17 Nicolas Cannasse <[hidden email]>
Le 16/10/2011 22:55, Juraj Kirchheim a écrit :

Hiho,

I've given a bit of thought to this discussion, and more generally to
the JS output of haXe. I agree there should both be an option to not
litter the global namespace as well as putting everything in there.
Also, while looking at things, I found there's quite a bit of
redundancies in the output and playing around a little I came up with
this: https://gist.github.com/1291347

It adds a little overhead (65 lines), but reduces the actual generated
code to something like this:

IMHO the default JS output should look much more like hand-written JS.

But since I know there is (at least) as many nice output as there is haXe/JS developers, then you can write your own custom JS generator in haXe thanks to macros.

Nicolas


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Skial



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org