time to trim mustache

[Brendan Eich]

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 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.

>> 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.

> 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
> https://mail.mozilla.org/listinfo/es-discuss