In .. an ES5/strict environment in which all primordial built-in objects
are transitively frozen, ..
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]; }
});
}
.. Given just a table instance, can Bob nevertheless obtain direct access
to the underlying array?
Hm. A favorite pattern that I haven't thought about enough, it seems.
My curiosity did cost me some sleep:-| My favorite work around for
your constraints is this little shim:-)
// dynamic language
Object.freeze = function(obj){return obj};
You imply that this is not intended, so I can show it without spoiling
the fun. I was surprised that this works.
The first solution that came to mind ought to be defeated by your
"transitively frozen" constraint, and it is, in current JS implementations,
though not all JS implementations in the wild are there yet - do you
"feature-detect" old engines and issue warnings if they invalidate
your base assumptions?
The second approach took longer to find but relies on non-standard
features (and again, I suspect a bug/interpretation issue).
Both ideas are weak, in that they could be blocked by type checks.
If you've already seen this puzzle and know the answer, please don't
post. If no one else has posted the correct answer in 24 hours, I will.
Neither of my approaches seems to be the droid you are looking for,
given your "no realistic fix" remark, so I'm curious what else I've missed.
Note that I don't see any realistic way to fix problem #3 in the ES.next
language. My point is only that defensive programming is tricky even after
you've gotten all the formal properties you need. As ES.next introduces
various new abstraction mechanisms, whether classes, enhanced object
literals, proxies, modules, or private names, the design of these can
either help or hurt those attempting to write defensive abstractions. Any
class abstraction that is only useful for making indefensible instances is
worse than useless -- it is actively harmful, both to security and to
serious software engineering.
You also rely on you security base framework being the first to run,
and on nobody trying to modify source on load, right?
Claus
http://clausreinke.github.com/
http://clausreinke.github.com/js-tools/
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
