doron's blaahg

Is it just me, or does the script used to show that presentation pretty much not work in any browser normal humans use? :)

And besides that font size and text positioning is so screwed for me I can't read it anyway. Dunno who's fault that is.

Presentation works for me, and I'm pretty human :)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060514 Minefield/3.0a1

Seems to work in IE7 too (which has fairly the same scripting capabilities as IE6).
Admittedly it looks very broken in both Opera 8.5 and 9.

What are the security implications of classes that are mutable by default? I can understand that if there were an in-built class/object in browsers called 'UsersConfidentialInformation', there'd be a problem if it were mutable --- but why is it better to *default* classes to immutable?

Also, towards the end of the presentation, it says 'Standard global properties (Date, String, etc.) immutable'. How does making the Date class/property immutable help security? (Or is it for performance?)

Just curious because I 'mutate' classes/objects pretty regularly.

Very interesting, but they still sadly want private object which would only make the platform less powerful (because many things are private in XBL it is not possible to extend it by only changing somthing from external JS)

"What are the security implications of classes that are mutable by default? I can understand that if there were an in-built class/object in browsers called 'UsersConfidentialInformation', there'd be a problem if it were mutable --- but why is it better to *default* classes to immutable?"

I believe the argument (not Brendan's, but web app dev's) is that if they are mutable, evil hacker could modify them using js and delegate information to his own server. I don't fully buy it, because if the hacker can load JS into the browser, he could overwrite whoever calls the class to call his own class (such as an onclick="" attribute).

"Also, towards the end of the presentation, it says 'Standard global properties (Date, String, etc.) immutable'. How does making the Date class/property immutable help security? (Or is it for performance?)"

Good question, perhaps ask it in the newsgroups?

Doron: objects created from a class C that you declare will be sealed, and their properties fixed, by default. That's not the same as the standard objects, which are not declared by, e.g., 'class Object { ... }' unless you bootstrap them. To keep backward compatibility, you would have to say 'dynamic class Object { ... }' and add extra declarative qualifiers to preserve the right amount of mutability.

The global properties Date, String, etc. becoming immutable does not mean that those constructor functions or their prototype objects are immutable -- only that window.String always === intrinsic:String as we hope to call it. We are investigating whether this is too incompatible a change. Much of the AOP-in-JS out there decorates or wraps advice around prototype object properties -- it does not replace String.

/be

May be possible open ways to people who want to switch to python from frustrating javascript?

> May be possible open ways to people who want to switch to python from frustrating javascript?

For browser-based web page and web app scripting? No.

For XUL, yes -- in Firefox 3 if all goes as planned.

Python is not something (CPython) we are going to ship, so you'll have to have it already on disk, in a version that Firefox can talk to (I understand the API is not stable).

Python does not have the security hooks, as far as I know, to be embedded in web pages. More to the point, web pages can't count on it working in any browser, so it won't be made to work in any browser. That's the reason JS is likely to remain (I'm not advocating here, I'm stating what I think is likely) the only browser-based web scripting language.

/be