On Thu, Sep 2, 2010 at 9:47 AM, Mark S. Miller <[email protected]> wrote:
> 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(); > Sigh. I sent too quickly. Here I meant 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 <[email protected]> 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 <[email protected]> >> 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 >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
