> That page currently has TBD semantics. Yeah, that's part of the work that needs to be done. Intuitively, it's a simple idea: ToName essentially generalizes the current semantics of property lookup; instead of trying to convert the property to a string, you try to convert it to a name-or-string. If it's already a name, it's a no-op; otherwise, it goes through the existing mechanisms.
IOW, everything behaves as before, except name objects are not converted to strings. > 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? The interface is different. With weak maps, you store soft fields off to the side; with private names, you actually get/set the properties directly on the object. > class Shape { > private draw() {...} > public coDraw(other) { > draw(); > private(other).draw(); > } > public shoot(gun) { > 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. These are good questions, but probably best to postpone till Sam has time to flesh out the strawman page. Dave
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
