On Oct 30, 2011, at 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?
I still think that <: might be an reasonable alternative, however it too will
have typography issues in some fonts.
>
> 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?
Of the various keywords that I been suggested for this operator, I think I like
it the best. It is probably good that it is fairly unique and idiomatic.
>
> Saying or writing "triangle" does not convey meaning, and it's confusing in
> geometry/graphics contexts.
yes, my original suggest is that <| should be produced "prototype for"
>
> 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'.
I kind of like the rationale of: You (JS users) asked for "classes" but they
really don't fit very well with the core concepts of the language we have to
build upon. We understand that what you really need is an expressive way to
define named abstractions over objects and that is something that we can
provide. The mechanism are a little different from in a class based language,
but actually quite similar.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
