Alternative syntax for <|

Irakli Gozalishvili rfobic at gmail.com
Mon Nov 21 17:55:06 PST 2011


Recently Claus Reinke proposed some alternative that I think feels is so much more natural and simpler than <| or beget: 

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


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


More information about the es-discuss mailing list