On Dec 22, 2010, at 12:45 PM, Peter van der Zee wrote: >> IMO, this is too class-oriented for JS. We should allow the >> creation of private members of arbitrary objects, not just those >> that inherit from new constructors. I think it also doesn't address >> the use case of adding new operations to existing classes like >> Object or Array without danger of name conflicts. > > Ok. Indeed it doesn't address adding private properties to any object nor > extending existing classes, although I think that might be fixable. And you're > right, it doesn't address conflicts.
Hold this thought ;-). >>> there...) - no need to introduce a new type/class to denote >>> private properties >>> >> >> This last point confuses me -- it sounds like you *have* to >> introduce a class to denote private properties, because they're >> associated with a class. Or are you referring to the SoftField type? > > The proposal at http://wiki.ecmascript.org/doku.php?id=strawman:private_names > lists three changes right at the top. 1 is a new type. To me, this seems like > a > rather big impact on the language for introducing something that's already > possible through closures. Wait, closures can't be used to avoid name collisions when extending existing objects (that held thought). The new type would be an internal, spec-only thing, were it not for #.id -- that requires typeof #.id == "private name" or some such. It all follows, but it's a hornet's nest in my view. An object subtype (internal [[Class]] property with new value "PrivateName", e.g.) would be less bitey. Allen's strawman raises this possibility, so it's not really the "hill to die on" -- it's not a big deal over which to shoot down the whole proposal. But it does draw fire that we might prefer held for bigger targets, I agree. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
