On 03/11/2011, at 23:55, Mark S. Miller wrote:
> 3) Although SES is *formally* an object-capability language, i.e., it has all
> the formal properties required by the object-capability model, it has bad
> usability properties for writing defensive abstractions, and therefore bad
> usability properties for use as an object-capability language or for serious
> software engineering. One example:
>
> In a SES environment, or, for present purposes, an ES5/strict environment in
> which all primordial built-in objects are transitively frozen, say Alice uses
> the following abstraction:
>
> function makeTable() {
> var array = [];
> return Object.freeze({
> add: function(v) { array.push(v); },
> store: function(i, v) { array[i] = v; },
> get: function(i) { return array[i]; }
> });
> }
>
> Say she uses it to make a "table" instance with three methods: add, store,
> and get. She gives this instance to Bob. Alice and Bob are mutually
> suspicious. All of us as programmers, looking at this code, can tell that
> Alice intended the table abstraction to encapsulate the array. Given just a
> table instance, can Bob nevertheless obtain direct access to the underlying
> array?
Yes, this:
function makeTable() {
var array = [];
return Object.freeze({
add: function(v) { array.push(v); },
store: function(i, v) { array[i] = v; },
get: function(i) { return array[i]; }
});
}
o= makeTable();
o.add(1);
o.add(2);
o.add(3);
o.add('Yay!');
o.store('__proto__', {push:function () { console.log(this) }});
o.add();
Gives:
[ 1, 2, 3, 'Yay!' ]
--
Jorge.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
