time to trim mustache

Irakli Gozalishvili rfobic at gmail.com
Tue Jun 5 17:16:50 PDT 2012



On Tuesday, 2012-06-05 at 16:06 , Brendan Eich wrote:

> Irakli Gozalishvili wrote:
> > 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)
> > 
> 
> 
> Object.define is the wrong name if the underlying operation at least for 
> data properties in the object passed as second aragument is, as it 
> should be, [[Put]] aka "assignment". Object.assign ain't great, though...
> 
> Object.set? [dherman]
> Object.update? [mikeal]
> 

I was coming from `Object.defineProperties`, but yeah any of that would make more sense to me. Object.extend makes me think of <| instead.
 
> 
> > I don't think new syntax is really necessary.
> 
> 
> Agreed in this case.
> 
> > 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.
> > 
> 
> 
> You wrote always and I must say "no". Some new semantics must come with 
> new syntax out of the box, e.g. let and const. You cannot expose APIs 
> for these (the ES5 Object API is not equivalent, we're talking about 
> binding forms). Modules are another example, especially the prefetching 
> form. Another example: generators.
> 
> > 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.
> > 
> 
> 
> If instead of "always" you wrote "where possible", I'd agree, but it's 
> still a bit too brain-off of a rule. In some cases I would go further 
> and say API only and never syntax! In other cases as noted, you can't 
> have new semantics without new syntax.
> 
 

Right I've being to extreme about it, but what I really meant is "where possible".


> > > 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
> > ))
> > 
> 
> 
> Is privates a constructor? This plausible, dherman suggested 
> Object.extend(target, source, privates) where privates is an array of 
> private name objects, even lighter weight I think.
> 


I'm sorry I messed up an example, I think what I meant was variation of this:

function definePrivates(target, pairs) {
   let index = 0, length = pairs.length;
   while (index <= length)
     Object.defineProperty(target, pairs[index++], { value: pairs[index++] })
  return target
}

defineProperties(target, [
  name1, value1,
  name2, value2
])
 
> 
> > Allen wrote:
> > > 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.
> > 
> 
> 
> JS does *not* provide APIs for all of its syntax, and never did. You 
> cannot "construct" statements or expressions other than by eval'ing a 
> string (no parse tree or AST reflection -- just one example).
> 
> Beware totalizing about syntax after semantics.
> 
> On Object.extend I think we agree, modulo best name.
> 
> /be
> 
> > 
> > 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 at mozilla.org <mailto:es-discuss at mozilla.org>
> > > https://mail.mozilla.org/listinfo/es-discuss
> > > 
> > 
> > 
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org (mailto:es-discuss at mozilla.org)
> > https://mail.mozilla.org/listinfo/es-discuss
> > 
> 
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120605/a3fce2ef/attachment-0001.html>


More information about the es-discuss mailing list