New private names proposal

[Brendan Eich]

On Dec 22, 2010, at 2:56 PM, David-Sarah Hopwood wrote:

> What I said, paraphrasing, is that weak encapsulation favours code that
> doesn't work reliably in cases where the encapsulation is bypassed. Also,
> that if the encapsulation is never bypassed then it didn't need to be weak.
> What's wrong with this argument?

The reliability point is fine but not absolute. Sometimes reliability is not primary.

You may disagree, but every developer knows this who has had to meet a deadline, where missing the deadline meant nothing further would be developed at all, while hitting the deadline in a hurry, say without strong encapsulation, meant there was time to work on stronger encapsulation and other means to achieve the end of greater reliability -- but *later*, after the deadline. At the deadline, the demo went off even though reliability bugs were lurking. They did not bite.

This is a common story from successful startups that I've been part of or advised.

The second part, asserting that if the encapsulation was never bypassed then it didn't need to be weak, as if that implies it might as well have been strong, assumes that strong is worth its costs vs. the (not needed, by the hypothesis) benefits.

But that's not obviously true, because strong encapsulation does have costs as well as benefits. It's often worth it, but not always. It may cost more than weak in the short run, but not the long run. It may cost more than it benefits in any time frame.

Yet your argument tries to say strong encapsulation is absolutely always worth it, since either it was needed for reliability, or else it wouldn't have hurt. This completely avoids the economic trade-offs -- the costs over time. Strong can hurt if it is unnecessary.

To be utterly concrete in the current debate: I'm prototyping something in a browser-based same-origin system that already uses plain old JS objects with properties. The system also has an inspector written in JS. Oh, and the system uses a framework where objects can be cloned using ES5's new meta-object APIs called by a clone method.

Now I want to make a private member of my objects, not for security but just to save my code from myself, who tends to use .x as a property name too much, and my colleague MonkeyBob, who likes to monkey-patch.

With private names, I just need to add the *** line to my constructor:

function MyConstructor(x, ...) {
   private x; // ***
   this.x = x;
   ...  // closures defined that use x
}

and I'm better off. Even if ES5's Object.getOwnPropertyNames is used by the inspector run by my other colleague ReliableFred, who needs to see x even though it is private. Fred won't do anything wrong with the value of x, but if he can't see it, he can't debug his code, which uses my code (the bug could be anywhere, or multi-factorial).

With soft fields, one has to write strictly more code:

function MyConstructor(x, ...) {
   const mySoftField = SoftField();
   mySoftField.set(this, x);
   ...  // closures defined that use mySoftField
}

And what's worse, I've broken ReliableFred's benign inspector use-case. And I've also broken clone. My boss finds out and fires me, we miss the demo deadline and fail to get funding, the company fails. Even the strong encapsulation angels cry tears of blood.

[big snip]


> I've also stated clearly *why* I want strong encapsulation, for both
> security and software engineering reasons. To be honest, I do not know
> why people want weak encapsulation. They have not told us.

Yes, they have. In the context of this thread, Allen took the trouble to write this section:

http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_name_properties_support_only_weak_encapsulation

Quoting: "Private names are instead intended as a simple extensions of the classic JavaScript object model that enables straight-forward encapsulation in non-hostile environments. The design preserves the ability to manipulate all properties of an objects at a meta level using reflection and the ability to perform “monkey patching” when it is necessary."

/be


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101222/23b56e54/attachment-0001.html>