It's simply that
var x = someProto beget { ... }
reads nicer then
var x = someProto extends { ... }
I'd prefer to have readability on the non class related operator then the
class related operator
On Wed, Nov 16, 2011 at 3:45 PM, Russell Leggett
<[email protected]>wrote:
> On Wed, Nov 16, 2011 at 10:31 AM, Jake Verbaten <[email protected]> wrote:
>
>> I think there was a naming discussion in another thread.
>>
>> Popular alternatives seemed to be "beget" and "proto"/"protos". I still
>> seem to like "beget"
>>
>
> The reason I suggest it is *entirely* based on its relation to the
> potential class operator. I see class operator combined with extends
> operator having a very natural feel (effectively makes Jeremy Ashkenas'
> class proposal happen), while still being able to be used orthogonally. The
> problem with beget or proto is that its still in the wrong place.
>
> const Point2d = class Point beget {
> ...
> }
>
> //or anonymously
>
> return class Point beget {...} //reads like you're creating a class
> Point here
>
> If class is off the table, then I would probably retract my proposal for
> extends. If class is on the table, but with leather and its own built-in
> extends keyword, I would probably still advocate for my form instead of <|
> because at least it would be consistent.
>
> - Russ
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
