Hi Kevin, thanks for pulling this code example out of the gist and posting separately. Looking at it only in context before, for some reason I hadn't realized how beautiful this is. To support this pattern, your makePrivate() could be defined either in terms of either private symbols or weakmaps, right?
Given how concise and beautiful this is, even if this is defined in terms of private symbols, I agree this looks much better than the square bracket syntax for accessing private fields. It also looks good enough that the hypothetical ES7 syntactic support doesn't look much better -- perhaps not better enough to be worth adding more sugar. As you say, this will give us enough experience with a usable privacy syntax that we can make a more informed choice for ES7 when it comes to that. Thanks! On Wed, Jan 23, 2013 at 7:30 AM, Kevin Smith <[email protected]> wrote: > > - Hosting getPrivate/setPrivate on Object seems quite strange to me. >> > > Reserve judgement for a bit on this... > > >> - it seems unrealistic to me to ask developers to write so much code >> every time they want to use their own private instance variable. The notion >> of Private should be specified once for an instance variable, not every >> time it's used internally >> > > Sure - eventually. But this proposal tries to take a smaller step in that > direction, without committing too much either way. Also, see the "simple > wrapping API" example in the gist. The amount of code is quite small if > such a wrapping is used: > > let priv = makePrivate(); > > class Purse { > > constructor() { > priv(this, { balance: 0 }); > } > > getBalance() { return priv(this).balance; } > > makePurse() { return new Purse; } > > deposit(amount, srcPurse) { > priv(srcPurse).balance -= amount; > priv(this).balance += amount; > } > } > > Yes, you have to use the "priv" function. But on the other hand you don't > need to create (say) 10 private symbols for 10 properties and use ugly > square brackets. > > And of course syntax will make all of this more concise in ES7. And when > it comes time to design ES7, the committee will have more real world usage > to inform the syntax. > > >> - I haven't followed the whole thread and I'm not a language developer. I >> never felt that I needed a private data structure to hold internal "stuff". >> One can already do that with a closure and a WeakMap manually if one really >> wants it >> > > Again, I think it might be more convenient to store properties in one > private object, rather than maintain several private symbols. But that > said, this proposal will allow you to use as many separate symbols as you > like. > > >> - I do want private instance variables that allow me to truly have >> encapsulation. >> > > Well here ya go! : ) > > Think of this proposal as a max-min version of privacy. It leaves WeakMap > as a pure data structure with specific GC semantics (like Allen wants), > while also providing the ability to do efficient rights-amplification (like > Mark wants). It simplifies the concept of Symbol (there is only one > "kind"). And it leaves a large degree of freedom for future improvements. > > { Kevin } > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
