That page currently has TBD semantics. Two questions: Syntax aside, is the observable semantics of Names different from < http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields>? How? If the only semantic difference is (not normally observable) less aggressive GC obligations, great. I'm confident we can converge those. Anything else?
On the syntax, the class-private instance field support at < http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar> allows, for example a shape class to have an class-private instance field named "draw" but nevertheless be able to address an unrelated normally-named "draw" property of other objects such as guns. It syntactically distinguishes normal property access from amplifying access: class Shape { private draw() {...} public coDraw(other) { draw(); private(other).draw(); } public shoot(gun) { draw(); } } In the names proposal, it seems that once in scope of a "private draw" declaration, all apparent uses of "draw" as a property name are amplifying. Even if the object being accessed has a normally named "draw" property, "gun.draw()" will fail to access it. Is that right? If all this will be addressed in the forthcoming love, I'm happy to postpone these questions till then. Thanks. On Thu, Sep 2, 2010 at 9:24 AM, David Herman <dher...@mozilla.com> wrote: > This is what the private names proposal is for. The page is a little stale > but Sam Tobin-Hochstadt is hoping to give it some love in the > not-too-distant future. > > http://wiki.ecmascript.org/doku.php?id=strawman:names > > The names go in the object, the link is strong rather than weak, the > property is non-enumerable, and even better than string keys, you can't > guess the name (either on purpose or by accident) unless you have a > reference to the name object. So it's a more reliable version of what you > described, but still straightforward to use. > > Dave > > On Sep 2, 2010, at 9:19 AM, Mike Shaver wrote: > > > On Thu, Sep 2, 2010 at 12:46 AM, Erik Corry <erik.co...@gmail.com> > wrote: > >> And this is as it should be. As it stands the weak map can be used as > >> an object with private members. The object key acts as a capability > >> that controls whether or not you have access to the private member. > > > > If I were to be using an object with private members, I would > > certainly expect that those members would keep their values alive. > > > > Wouldn't it be better to just use a regular object, and add private > > members via defineProperty to make them non-enumerable? > > > > I'm not in favour of WeakMap enumerability, really, but it seems that > > there's an easier way to address this particular use case. > > > > Mike > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
