On Jun 1, 2012, at 8:52 AM, Kevin Smith wrote:
> Regarding private names: I'm not convinced that private, non-reflective
> names are unproblematic in and of themselves. I would personally like to see
> more exploration on this front, with concrete use-cases. What useful things
> can we do with private names that we cannot do with globally unique names?
Briefly, some high-level rationale:
// -----
1. Paving cowpaths: Crockford's closures-for-private-properties pattern but
without the per-instance costs:
function CrockClass() {
var myPrivateData = ...;
// one copy per instance
this.myMethod = function(...) {
... myPrivatedata ...
}
}
// versus:
var myPrivateName = new Name();
function ES6Class() {
this[myPrivateName] = ...;
}
ES6Class.prototype.myMethod = function(...) {
... this[myPrivateName] ...
}
2. Untamperable object properties:
var score = new Name(); // no cheating from the console!
function GamePlayer() {
this[score] = 0;
}
3. Classes that are easier to subclass without name clash concerns:
// super.js
var myPrivateName = new Name();
function MySuperClass() {
this[myPrivateName] = ...;
}
// sub.js
var myPrivateName = new Name();
function MySubClass() {
this[myPrivateName] = ...; // no clash :)
}
// -----
I agree that unique is often "private enough." I still favor private names that
can either be unique or private depending on your needs. And maybe they should
default to unique, not to private. But it should still be easy to make them
truly private. For cases where you truly need robust information hiding,
private names are more ergonomic than closures.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
