I just want to (re)express my (and many others) concern about new syntax. While Object.extend adds useful feature (Although I think Object.define would be more appropriate name) I don't think new syntax is really necessary. I do think that new syntax needs a lot more justification then new semantics. I also would argue that it's a good idea to alway make syntax changes in a separate iteration from the one where associated semantics have being introduced. That would allow both community and come tee to see these semantics in practice and having more knowledge to decide what syntax sugar would work best, if any new syntax even will turn out to be necessary. > > > > > One of these things is installing private named properties upon an existing > object. As currently specified, those could not be communicated to an extend > function via an object literal because we have disallowed any form of > refection upon private named properties. Object.extend could not see them on > the literal object in order to copy them. Trying to solve this problem by > saying that Object.extend has special reflection privileges would violate the > encapsulation that the non-relection on private name properties was intended > to provided.
But many other variations of this would do the job as well without a new syntax: Object.extend(target, privates( name1, value1, name2, value2 )) > > Anther ES6 specific semantic that has always been part of the mustache > proposal is the correct binding of methods with super references. I've > described this many times. So I'll just describe it again other than to > reinforce that mustache is the great way to dynamically associate super > referencing method to an object without running into the pitfalls that arise > with the defineMethod alternative. I see how with mustache we can live > without defineMethld. But omitting reflection APIs is pretty dangerous path to go with IMO. JS has being great as it was always possible to fix things that were not working for you. I have feeling that providing semantics only through new syntax may take away this great power of JS. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Monday, 2012-06-04 at 09:45 , Brendan Eich wrote: > Kevin Smith wrote: > > Thanks Dave, > > > > Of the 3 use cases you mentioned, I think unique names are probably > > sufficient for 1 and 3. For the second use case (an inaccessible > > piece of data associated with an object), would not a weak map also be > > appropriate? > > > > > No, WeakMaps have two problems we've covered in this list: > > 1. Less efficient than private names. > > This matters when you can least afford it, and it matters for private > names used to program in the large using objects in JS. WeakMaps require > special GC handling and they're an extra object with internal mutable > state. Private name objects are flat, frozen, and can be optimized a lot > harder. > > 2. You cannot abstract property access: > > function get(obj, prop) { return obj[prop]; } > > works with a private name object referenced by prop. No such abstraction > can be done with a weak map. > > /be > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org (mailto:es-discuss@mozilla.org) > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
