Private Slots

Kevin Smith khs4473 at gmail.com
Wed Jan 16 22:16:08 PST 2013


> That's what happens with "private" in Java (I don't think most Java devs
> think that the Reflect API makes their private attributes actually not
> private). Java devs could make everything public, they choose not to
> because the cost of putting "public" is the same as the cost of putting
> "private" and the benefits are known. In ES5, high integrity privacy has a
> cost both in code readability and runtime, that's why people don't use it.
> It's not that they don't need it, it's just that getting to high integrity
> is annoying.
>

First, let's point out that Java's private members are for the most part
reflectable, and as such they are more akin to unique symbols than private
symbols.  For OO design purposes at least, we don't need high-integrity
privacy.


> Every project of a decent size needs high-integrity privacy. This
> shouldn't have a barrier to entry. It should just be what people do by
> default. Security shouldn't be considered as a luxury left to experts. It
> should be what naturally comes from writing our code.
>

I would be willing to admit that every project needs high-integrity
privacy, but not without proof.  Volumes of code have been written for the
Node platform, which is inherently low-integrity.  Is the lack of security
there a cause for concern among developers?

Let's take your microwave analogy.  There is a clearly defined danger
involved with opening the door while the thing is still running:  you'll
end up blasting your face with radiation.  Similarly, we need to clearly
define the danger of low-integrity abstractions before we can talk about
changing the object model to avoid those dangers.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130117/0b5ddac9/attachment-0001.html>


More information about the es-discuss mailing list