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