Alternative syntax for <|

[Dmitry Soshnikov]

On 22.11.2011 5:55, Irakli Gozalishvili wrote:
> Recently Claus Reinke proposed some alternative that I think feels is 
> so much more natural and simpler than <| or beget:
>

Yes, it was proposed long time ago:

https://mail.mozilla.org/pipermail/es-discuss/2011-May/014391.html

let foo = {x: 10};

let bar = {

    #proto: foo,
    #closed

    y: 20,
    // etc.

};

And the reply was (by Allen) -- 
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014407.html that 
in contrast with only inheriting from simple objects (that is of 
[[Class]] "Object"), <| allows to inherit different object [[Class]]es 
(functions, arrays, etc).

But, yeah, it could be a good sugar.

Dmitry.

> Instead of this:
>
> foo <| { bar: 'bar' }
>
> prototype can be a special property:
>
> { prototype: foo, bar: 'bar' }
>
> simple and easy, of course it can have a different name from 
> `prototype`. Also, this special `prototype` property can be 
> non-configurable, non-writable and non-enumerable falling back to 
> Object.prototype if not provided. Also Object.create(null, { foo: { 
> value: 'foo' } }) will become as simple as { prototype: null, foo: 
> 'foo' }.
>
> Regards
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
> Address: 29 Rue Saint-Georges, 75009 Paris, France 
> <http://goo.gl/maps/3CHu>
>
> On Monday, 2011-11-21 at 10:10 , Allen Wirfs-Brock wrote:
>
>>
>> On Nov 19, 2011, at 11:38 AM, Dean Landolt wrote:
>>
>>>
>>>
>>> On Sat, Nov 19, 2011 at 1:57 PM, Allen Wirfs-Brock 
>>> <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>>>>
>>>> On Nov 15, 2011, at 10:27 PM, Russell Leggett wrote:
>>>>
>>>> >
>>>> >
>>>> > but given the overall disapproval of the exact syntax of the <| 
>>>> operator, I think its at least a little more obvious what is going on.
>>>> >
>>>>
>>>> Sorry to be coming late to this thread.
>>>>
>>>> I think the above statement is a false characterization to use to 
>>>> start this discussion.  There are some who disapprove of <| or 
>>>> other similar special character formulation of this operator. There 
>>>> are other who like it a lot.  Certainly there isn't "overall" 
>>>> disapproval.  However, we can't really even tell whether there is 
>>>> majority (of what population??) approval or disapproval.  At best, 
>>>> all you can legitimately say is that there is not universal 
>>>> approval of the <| token.
>>>
>>>
>>> I was under the impression that TC39 generally operates 
>>> by consensus. As you note, there are some who disapprove -- if 
>>> /some/ is a non-inconsequential number wouldn't this constitute 
>>> /overall disapproval/?
>>
>> It's true that there isn't consensus within TC39 on the "<|" syntax. 
>>  However, there also isn't consensus on any other specific token or 
>> keyword either.  At the May TC39 meeting there was consensus on 
>> "advancing to proposal status"  the semantic capabilities that were 
>> in the enhanced object literal strawman.  At the same time it was 
>> noted that there wasn't agreement on syntax.
>>
>> Lack of consensus does not mean "overall disapproval".  It means 
>> there isn't overall approval.  Further consensus building is still 
>> required it might be around the pending proposal or it might be 
>> around something else.
>>
>> However, TC39 wan't even mentioned in the statement I took exception 
>> to.  It seemed to make a broader subjective characterization.
>>
>>>
>>> FWIW I'm indifferent to the syntax, but it reads just fine to me. 
>>> Still, I'm sure there's something better lurking. Especially if it's 
>>> true that since it's infix it could be nearly anything. IMHO 
>>> "begets" is pretty winful.
>>
>> I find keywords such as "begets" a bit more jarring when used as 
>> compositional primitives.
>>
>> To me, "beget" reads fine in isolation such as
>>       let bob = tom beget {name:  'Robert');
>>
>> But when used in combination you get clashes of the underlying 
>> natural language meaning of the keywords.  Compare
>>       let Point = class AbstractPoint begets {...
>> to
>>       let Point = class AbstractPoint <| {...
>>
>> The first form just doesn't "read" quite right to me.  For the second 
>> form, I don't necessarily internally vocalize a natural language word 
>> for <|.
>>
>> My personal preference is  for a special characters based operator 
>> based token but it doesn't have to be <|.  I've frequently suggested 
>> <: as another alternative.  I'm less happy with a keyword operator 
>> token but I don't reject that alternative and "beget" may well be the 
>> best of those.
>>
>> However, we have to decide on something or we just won't have this 
>> functionality at all.
>>
>> Consensus doesn't mean that everybody likes the solution.  It just 
>> means that everybody is willing to accept it. What we really need to 
>> do is build such a consensus around one of the alternatives.
>>
>> Allen
>>
>> _______________________________________________
>> 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

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