On Wed, Jan 21, 2009 at 7:09 AM, Kris Zyp <kris@...
> Do you have an overview of the differences between SES and ES3.1
Three synergies between ES3.1 strict and SES:
* Better target: Easy to translate SES to ES3.1-strict
* Better source: Easier to translate ES3.1-strict to SES
* Better neighbor: ES3.1 code can't violate SES objects.
First, SES is a subset of ES3.1-strict, so I'll start with that.
* Most important: all primordial state -- all objects and all state reachable from the global scope -- is frozen. In other words, the global object itself, as seen from SES, is immutable (deeply frozen). Only by imposing this rule can the global object be safely shared by separate protection domains that must remain isolated from each other.
** global eval() evals SES,
** Function constructor is suppressed.
** Math.random(), new Date(), and Date.now() are suppressed.
** for/in loops in deterministic order.
* No "this"
** foo(..) equiv to (true && foo)(..)
* no override of Function.prototype.(call/bind/apply)
** for functions, foo(..) equiv foo.call(??, ..) equiv foo.apply(??, [..])
* All functions are frozen before first use or escaping occurrence:
** Anonymous functions are born frozen.
** If "foo" is a named function, one can initialize "foo.prop" in straight line code between its definition and first non-initializing use.
** Function names define unassignable variables (as if with const, but with function-like hoisting rather than a read barrier)
* Only built-in functions have function prototypes
** Function prototypes are not first class: <function>.prototype and <prototype>.constructor are not whitelisted.
* No RegExp literals -- use RegExp constructor.
* No semicolon insertion.
SES code can only define records, arrays, and functions. Objects other than these but represent pre-existing libraries (and other tamed legacy). All such objects are sealed.
> maybe it is easier to define the differences between SES and Cajita)?
Current Cajita does not allow control of the attributes of individual properties. Rather, a record or an array is either frozen or not. If it's not frozen, then all of its properties are mutable.
Likewise, one cannot define new getter/setter properties within Cajita code.
> I see a lot of [[Prototype]] -> [[Parent]] changes, but maybe you
> could summarize the important differences?
That one is only cosmetic. Since the ES3.1 explicit "prototype" property is not whitelisted, but is still needed to account for the semantics of built-in libraries and tamed legacy, it will be explained as an internal property. To prevent confusion, I am rephrasing to avoid the term where another term would do as well.