I've been noodling around with various syntax ideas in this post, and it
has gotten pretty long, so here are the highlights:
var obj = base <| {a:1,b:2}; // I think its okay as-is.
var obj = {:base> a:1, b:2}; // Its not really an operator, anyway
var obj = base prototype {a:1,b:2} // Prototype with pride!
var obj = base share {a:1,b:2} // JS: the friendly language
var obj = with(base) {a:1, b:2}; // :-)
If any of these intrigue you, read on for my thoughts on why punctuation
is okay in this case, and why I've proposed syntax that is not an operator.
I'm sympathetic to the anti-grawlix position. In this case, however,
we're discussing an operator that is *fundamental* to the language and
gets right to the heart of JavaScript's prototype system. The reason it
is hard to name is that there is no precedent in other languages.
Because it is fundamental and unique to JavaScript, people will think of
it as "that weirdly cool JavaScript operator". So, do we want them
thinking "that weirdly cool operator that doesn't quite look like a
triangle" or "that weirdly cool operator that sounds sort of biblical"?
I'm only sort of joking about that. My more serious point is that
prototype-based inheritance is something that new programmers have to
take some time to learn. Having to learn one new punctuation-based
operator is really no extra effort, especially when it is such an
important one. There have been previous proposals (I'm thinking of one
for setting property attributes in object literals) that really did seem
to increase the line-noise quotient of the language. But the triangle
operator isn't one of those.
If the concern is just about the typography of <| not looking triangular
enough, how about <*, where < shows the direction of the relationship
and * says "this is really special and important" :-) Or, <-?
It is also worth thinking about the fact that <| is a very unusual
operator because the RHS must be a literal. Like the . operator for
property access which requires an identifier on the right, it could be
considered a syntactic form that is not quite an operator. So could we
put syntax before and after the proto object to make this an easier to
understand concept? Like this:
var obj = with(base) { a:1, b:2};
Redeeming with would be pretty cool, but I assume it would cause to much
confusion to consider seriously. So what if the base object was between
the | and the arrow:
var obj = |base> {a:1, b:2};
I know that changes the direction of the arrow around, but I suspect
that pointing at the derived object is actually more intuitive for most
programmers, anyway. I don't know if this syntax works in the grammar,
and it looks a little phallic (the "rocket" operator ;-), but to my eye,
it helps to convey what is going on better than a simple infix operator.
Or, to emphasize that this new syntactic form is all about specifying a
prototype for an object (or array, function, or regexp) how about
forcing it all to be within curly braces?
var obj = {:base> a:1, b:2};
var arr = {:base> [a,b,c]};
var func = {:base> function(...args) {...}};
var re = {:base> /pattern/g};
(I'm using a colon here instead of the vertical bar because I'm still
hoping for block lambdas...)
Setting a prototype on an array object is an unusual enough thing to do
that I think it can certainly justify the wrapping and even extra
indentation that comes with putting [] inside {}.
If its got to be an infix keyword operator, I'm not crazy about
"beget". I'd prefer "proto". And actually, I'd even prefer to type the
extra 4 characters and use "prototype" because it is a verb. JavaScript
has prototype based inheritance, so let's wear that proudly and make it
a keyword operator.
The next best I can come up with is "share". (That is assuming that
"sub" and "subclass" are off-limits because ES.next.next may someday
have a "class" keyword.)
If the left and right-hand sides of the operator were swapped, it would
be easy to name the operator: "inherit" would be an obvious choice. We
need the inverse of "inherit", something like "designate an heir", but I
don't think English has a word with that meaning. The word "heir"
itself is nice and short, but I assume that the fact that it is not a
verb disqualifies it.
So if we can't find a good keyword using the
inheritance-by-children-upon-death-of-the-parents metaphor, we can go
for parent/child metaphors, which is where beget comes from. And from
biology we can go back to inheritance in the form of genetic
inheritance. If the prototype object is like DNA (and its properties
are genes) is there a verb we can draw from genetics to describe what
the operator does?
Or, can we just break away from the family tree/inheritance metaphor
entirely and just say what the operator does? That's where my "share"
suggestion comes from: the prototype object shares its properties with
the derived object.
David
On 10/30/11 3:36 PM, Brendan Eich wrote:
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it builds upon
features that are already in JS. Specifically, it uses the new operator instead of a new
method and it names the initialization method "constructor" in order to tie
into the object construction mechanisms that already exist in JS.
+1
The only thing I find off the mark is the typography of<|. In light of this,
and of the anti-grawlix reaction among many people, could we revisit an infix
operator used in restricted productions with [no LineTerminator here] on the left
of the operator contextual keyword?
Likely keywords include 'proto' (but 'protos' seems better English given the
LHS being the prototype object), or my current best shot: 'beget'.
let obj = base beget {a: 1, b: 2}
let arr = base beget [p, q, r]
let fun = base beget function (...args) { ... }
let re = base beget /(\w+)\s+(\w)+/g
It's still idiomatic as a name for differential inheritance, but it is more
pithy than 'make' or 'create' (and one character shorter than 'create' -- no
Unix 'creat' reruns! ;-). Comments?
Saying or writing "triangle" does not convey meaning, and it's confusing in
geometry/graphics contexts.
While I still think 'class' is easier to teach, there's a risk if JS has
'class' syntax that desugars to constructors with prototypes. And with your
exemplar proposal, if we're really going to level the prototype/constructor
playing field, then we need more than 'new'/'constructor' protocols for objects
as well as functions. We need 'beget'.
/be
_______________________________________________
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
