Security Demands Simplicity (was: Private Slots)

Mark Miller erights at gmail.com
Thu Jan 17 10:42:23 PST 2013


I just looked back at the example code in "Distributed Electronic Rights in
JavaScript". It uses WeakMaps in two places: Fig1 line2 and Fig3 line2.
Both of these express objects using the objects-as-closures pattern, not
using classes. It's clearly affordable here since there are only 3 and 2
methods respectively. In both of these, the use of WeakMap has the lifetime
properties I point out -- the weakmap's keys can never outlive the weakmap.
The pattern, as you see there, expressed manually without any classes, is
syntactically quite pleasant. Implementations that use Ephemeron gc
techniques to implement these weakmaps will be outperformed by
implementations that simply hang the private value state off of the key
object. These manual uses of WeakMap would use the hint if such a hint
existed.


On Thu, Jan 17, 2013 at 10:30 AM, Mark S. Miller <erights at google.com> wrote:

> On Thu, Jan 17, 2013 at 10:02 AM, David Bruant <bruant.d at gmail.com> wrote:
> > Le 17/01/2013 18:00, Mark S. Miller a écrit :
> >
> >> However, after the "Private Slots" thread, I spent a sleepless night
> >> chewing on getting rid of private symbols.
> >
> > Happens to me so often :-)
> >
> >
> >> I now think we should.
> >> Going back to my earlier
> >>
> >>
> >> On Wed, Jan 16, 2013 at 12:37 PM, Mark S. Miller <erights at google.com>
> >> wrote:
> >>>
> >>> My position on private symbols.
> >>>
> >>> My position on classes is and has always been that classes are worth
> >>> introducing into the language *only* if they give us, or can be used
> >>> with, an affordable means for true object encapsulation. Assuming
> >>> Allen is right about what actual implementors will do (which I find
> >>> plausible) then WeakMaps are not that means.
> >>
> >> I still have this position on classes. But I no longer buy that
> >> pessimistic conclusion about WeakMaps. Consider how WeakMaps would be
> >> used by the expansion of classes-with-private. Just 'cause it's on the
> >> top of my head, below I use the old representation of one WeakMap per
> >> class providing access to a record of all the private state. For the
> >> same reason, I'll use the encapsulation of the Purse example without
> >> any of the numeric checks.
> >>
> >> class Purse {
> >>      constructor(private balance) {
> >>      getBalance() { return balance; }
> >>      makePurse() { return Purse(0); }
> >>      deposit(amount, srcPurse) {
> >>          private(srcPurse).balance -= amount;
> >>          balance += amount;
> >>      }
> >> }
> >>
> >> expansion
> >
> > I don't understand the need to expand. This is the class syntax. It
> creates
> > a constructor. Instances of this constructor have some behavior and
> > characteristics described by the class body. If the class body allows to
> > define something private, implementors will implement that and work very
> > hard on performance. I don't think implementors will expand before
> compiling
> > and using the class syntax as some sort of macro (implementors are free
> to
> > tell I'm wrong here).
> > Assuming I'm right, what it expands to exactly does not matter much,
> whether
> > it's private name or weakmaps or whatever else.
>
> Regarding what I actually said, you're right. I am being unbelievable
> confusing this morning. After that sleepless night, I should probably
> wait till I'm rested before posting again. Foolishly perhaps, I'll try
> to answer anyway.
>
>
> 1) It remains useful to define the semantics of classes by expansion.
> Then one can reason about classes by reasoning about the expansion.
> This is especially helpful for automated tools. The semantics had then
> better be faithful to the explanatory expansion.
>
> 2) Until ES7 provides private, there will be transpilers that provide
> actual privacy by other means.
>
> 3) Most important, and most unsaid by my previous email: In ES6, since
> there's no built-in class/object privacy mechanism, ES6 programmers in
> general and ES6 class programmers specifically have to achieve real
> privacy by other means -- by engaging in some pattern using other
> constructs. Previous conversations assumed that these patterns would
> be expressed in terms of private symbols. Absent private symbols, the
> pattern shown by my expansion above, as painful as it is, is what will
> be expressed manually. By the time ES7 rolls out, there will be a lot
> of that code.
>
>
>
> >
> > Now you're only talking about privacy in the context of classes in this
> > post. I understand this as assuming private symbols would be only use in
> > class or class-like contexts (after referred as "this assumption" or "the
> > assumption").
> > If that's your assumption, then I agree that if classes have a "private"
> > syntax that is efficiently compiled, private symbols can be dropped.
> > It has to be noted that if private symbols are dropped, the set of
> private
> > properties is sealed once and for all in the class body. That is, it's
> not
> > possible to add or remove a private property after initialization.
> (However
> > it remains possible to privately attach information to an object with a
> > weakmap kept private)
> >
> > If "private symbols will be only used in class or class-like contexts" is
> > your assumption, let's talk about it. Historically, JavaScript objects
> have
> > been used in both in OO contexts and as maps. This confusion led to some
> > bugs (involving __proto__ for instance)
> > As I have suggested in another recent post, most of the time, objects in
> OO
> > contexts are pretty stable: they are created with a given set of
> properties
> > which doesn't change. This stability could even be declared statically
> > (that's what the class syntax does actually).
> > However, for the map use case, it makes sense to add and remove
> properties
> > at runtime.
> >
> > ES6 adds actual maps, so objects (especially the ones instanciated after
> > class-born constructors) could be legitimately considered as reserved
> for OO
> > contexts.
> > That's a reasoning I agree with since I can't think of cases besides
> classes
> > where private symbols would be used and for which weakmaps wouldn't be
> > better.
> >
> > So I guess I agree with the removal of private symbols given classes
> have a
> > syntax for private properties and no other relevant use case for private
> > symbols is found.
> >
> > David
>
>
>
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130117/65987319/attachment-0001.html>


More information about the es-discuss mailing list