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 <[email protected]
> > (mailto:[email protected])> 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
> [email protected] (mailto:[email protected])
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
