Some questions about Private Name Objects

David Bruant bruant.d at gmail.com
Tue Aug 28 07:24:15 PDT 2012


Le 28/08/2012 15:38, Kevin Smith a écrit :
> Apologies in advance for the length...
Don't. We're here to discuss as the mailing-list name suggests. And if 
what you need to say is long, so be it.

>     A huge share of this complexity has been removed in recent
>     discussions [1]. Conclusions seem to have reach consensus on
>     es-discuss, but nothing has been officially accepted by TC39
>
>
> As I understand it, the solution arrived at was to provide a (possibly 
> updatable) collection of private name objects to the Proxy constructor 
> and let the engine take care of the details.  That sounds good, and 
> good work!
Exactly. I'm glad there is one more fan of the proposal :-)

>     What do you mean? Private name allow to do mixins without
>     collision. It seems to reduce the complexity than increasing it in
>     my opinion.
>
>
> Unique (non-private) names offer mixins without collisions.  But any 
> general mixin utility will fail if the source  object relies on 
> privately named methods for its functionality:
>
> (code snippet)
>
> Neither the destination object nor the library function "mixin" has 
> access to the private name, and therefore the privately named method 
> will not get copied to the destination object, and the mixin will fail.
>
> Clearly the solution above would be to use a unique name, instead of a 
> private name.
Indeed.

> But that begs the question: why do we need private, secured names at 
> all?  They complicate the object model without a compelling use case, 
> as far as I can tell.  If there are use cases, let's see them.
Private names enable easy encapsulation & code sharing at the same time 
(which is awkward at best nowadays).
As a result of the current awkwardness, developer sacrifice 
encapsulation by using publicly accessible fields using the _field 
convention. I could name dozens of Node.js library doing that.
And sometimes, developers use a private field while they shouldn't, but 
it makes their life easier, and abstraction leak, etc.

It all start because of a fundamental missing piece in the language that 
is the ability to add a private property to an object. Not socially 
private as per the _field convention. I mean actually private, enforced 
by the runtime.

> In any situation where you want to *really* secure access to data or 
> code, the ergonomics of your code is going to be the least of your 
> worries.
I disagree. A good part of the work toward securing an application is 
reviewing it. The easier the review is, the less likely you are to leave 
holes behind. The ergonomics of the code is a security feature.

> Security is just generally difficult, and that "soft-tissue" cost will 
> have to be borne by the developer whether they use WeakMaps or private 
> names or closures or whatever.  Why complicate the object model, and 
> in the process invalidate the current maxim that all properties are 
> reflective, when the weight will still fall on the developer anyway?
I arrived on es-discuss at a time where private names had been decided 
to be the mecanism that answer all above-listed constraints. It seems to 
do the job. I have intuitive concerns about how to use them in large 
scale applications and preserve proper code sharing, but nothing 
concrete to either validate nor invalidate this intuition. In a 
nutshell, I'm wondering whether private names will be easy to use in 
complex cases.
I'm not specifically against the idea of complicating the object model 
if the benefit is developers stopping _fields. I am open anyway to see 
if there is an idea that's alternative to private name and would solve 
all above constraints.

There is still time since no one has implemented private names (or 
symbols as it's their new name which I'm still not used to) yet.

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


More information about the es-discuss mailing list