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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
