He wrote: I'd like to know your opinion about JS2 ...

... and here I am.

My opinion about ECMAScript 4 is not that simple to explain.

I would like to have a language, whatever it is, that is powerful, truly natively cross browser, and widely adopted from every kind of device.

It seems I am talking about ActionScript, since Flash Player respects, aproximatly 90%, my desires, but I am not.

I "come" from Macromedia world, as a Certified ActionScript 2.0 Developer (no design guys, only pure AS2 OOP), and I have used, for years, Flash as production environment.

Looking at the little "JS2 monster" they are creating, I could smile, thinking about problems I had for those years with an environment that would like to be compatible with both old and new code, loads of unresolved bugs, and never perfectly cross browser ... we just have them, it is JavaScript, with its numerous implementations.

At the same time, I would love to see JavaScript 2 power, in a bytecode based VM, but what I do not want, is a partial implementation of this new language, as I do not hope in a JS3 project at all ( Macromedia style, every maximum 1 or 2 years a new language, so that nobody was really skilled and nobody knew perfectly the environment and language features itself ... welcome Adobe, and its hybrid Flash player that could do more, but only with Flex ... but it is only about marketing, isn't it? )

After 10 years or more, we are still "discovering" patterns and practices for a language born so far ( today, as example, another post about prototypal inheritance, using bad practices to perform simple, and logical, tasks - this is the state of general JS knowledge, 2008 )

Furthermore, as far as I know, Microsoft invested a lot of effort for its SilverLight pearl, a technology that, after years, is not that far from what Adobe, and Macromedia before, has done during these web evolution days and for long time.

I think, and it is only my humble opinion, that MS will never implement natively in its browser an open source VM, which purpose is to make Web more standard, at least for development, and more powerful for everyone:

You want more for your browser? You want SilverLight!

We would like to have canvas ( fast graphic? SilverLight ), standard behaviors, libraries which size could be 1/3, removing every single line IE dedicated ( fast and easy development? SilverLight ) ... but we still have attachEvent, old Array methods, and we know what else.

So, definitively, if JS2 will be the key to write once and run everywhere, without 3rd parts plug ins, without strict usage licenses, with more speed, more power, and capable to run in every device, I cannot wait that day ... but I am pretty much sure, that it is not close as I hope.

What about solving problems with ECMAScript 3rd edition, fixing everything, and in every browser? A dream, or better, an utopia!

So let's start to learn, to develop, and to fix, a new language :geek:

scary eval to create the most safe environment ever

Are you worried about Array redefinition?
Are you worried about eval function redefinition?
Are you worried about whatever you want redefinition?
STOP
With the incredible eval feature "discovered" few days ago, it possible to create the most safe environment ever for every kind of purpose, starting from JSON evaluation, arriving to total protected native constructors.

const safeEnvironment = function(A, B, D, F, N, O, R, S){
    const   Array   = A,
            Boolean = B,
            Date    = D,
            Function= F,
            Number  = N,
            Object  = O,
            RegExp  = R,
            String  = S,
            eval    = function(String){
                return  self.eval("(" + String + ")");
            };
    return  new function(){};
}(
    Array,
    Boolean,
    Date,
    Function,
    Number,
    Object,
    RegExp,
    String
);

With above piece of code you can evaluate every kind of script without to be worried about common XSS or evaluation problems.

eval("Array=function(){}; alert(Array);", safeEnvironment);
/*
function Array(){
    [native code]
}
*/

Seems to be hilarious, isn't it? The most scary Gecko function let us redefine entirely an environment, using constants to create immutable values that will be present in the virtual sandboxed scope.

So, the paradox, is that with Gecko eval, we could create the perfect safe environment, that could be used for every purpose, starting from the NoScript stuff.

Please, help me to convince Mozilla staff that second argument is not dangerous and could make our code execution safer than ever, thank you!

SCARY EVAL ... and the "futuristic" solution

Planet Earth, Year 2000

eval("document." + myformName + "." + myInputName + ".value");

Satellite Moon, Year 2004

eval is evil, nobody should use them, "except for json evaluation"

Planet Earth 2.0, Year 2008
OMG somebody could penetrate my closures!!!


Web Reflection, few days later
First of all, it was in the MDC, so if everbody is surprised, it is because we did not read that page, or simply we did not try that code (please correct that page, the second argument is everything but not the same of with statement).

Secondly, please, DO NOT CHANGE THAT FEATURE!!!
What I mean is that JavaScript is an amazing language, where everything could be changed, thanks to its intrinsically dynamic nature.

If we are worried about this fake news:

• we should worry, before, about XSS in our site (after SQL injections)


• if we are sure about missed XSS possibility, we should be worried about external libraries


• if we are sure about third parts libraries, we should be worried about JSON


• if we are sure about external libraries and JSON interactions ... why on heart should we be worried about this historic feature?

The feature is present in Gecko, but hey, Gecko implements constants!!!
Another thing I could not understand, is why somebody opened a bug for a feature that could be AMAZING if used for our own purpose.

Code and closure introspections, protected method implementation, whatever I cannot imagine right now.

On the other hand, it is extremely simple to solve the problem using a basic constant declaration

// webreflection "from the space"
try{eval("const $eval=function(eval){return function($eval){return eval($eval)}}(eval)")}catch($){$eval=eval};

Now try to delete the constant, try to do whatever you want in FireFox, and if it will be possible to change that $eval behaviour with Gecko browser, that will be the only bug you should really fix.

With Best Regards,
your bloody evil propagator ( booh! )



Update
Since I am writing in the bug page, I think my example could be interesting to understand what we are going to loose when this feature will disappear:

// sandbox: redefined environment
var myEnvironMent = {
 eval:function(script){
  return eval(script);
 },
 alert:function(String){
  (document.body || document.documentElement)
   .appendChild(document.createTextNode(String));
 }
};

// evaluate a script from a string or a textarea
eval("alert('Hello World')", myEnvironMent);

/* you cannot do this with a with statement
with(myEnvironMent)
 eval("alert('Hello World')");
*/



// privileged protected methods in prototype
Protected = function(){
 function _showMessage(message){
  alert(this.name.concat(" say ", message));
 }
 return function(name){
  this.name = name;
 };
}();
Protected.prototype._ = function(method){
 return eval("_" + method, this)
  .apply(this, Array.prototype.slice.call(arguments, 1));
};

var p = new Protected("Andrea");
p._("showMessage", "Hello World");

These are only two quick examples, and I wrote them in 1 minute.
Now try to imagine what could be possible to do having such control over closures!