WeakMap API questions?

Mark S. Miller erights at google.com
Thu Sep 2 09:50:52 PDT 2010


On Thu, Sep 2, 2010 at 9:47 AM, Mark S. Miller <erights at google.com> 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 <dherman at 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.corry at 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 at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>



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


More information about the es-discuss mailing list