Yet another class declaration proposal

Russell Leggett russell.leggett at gmail.com
Thu Nov 3 11:17:03 PDT 2011


>
>
> I know this will be controversial, but I would prefer only having the
> expression form.  The reason is that
>
> let Monster =  Being <| mylib.mixin(Evil, Scary) <| class {...}
>
> is an important usecase and it is harder to make the syntax work with a
> pure class declaration.
>
>
I'm not sure if you saw  my proposal https://gist.github.com/1332028 (its a
little long, I apologize), but it is very similar to this except instead of
unifying class extends and <| by using <| for classes, I went the other
way. I did this because people don't really seem to like <| syntactically.

What I wanted to bring up here, though, is your desire for:

let Monster =  Being <| mylib.mixin(Evil, Scary) <| class {...}


which is something I suggested in my own proposal (more or less). However,
this example, as much as I like it, clearly breaks rule of only allowing
literals on the RHS of <|. I would like to break that rule as well, and I
was curious how you proposed to solve it. What is your opinion of my
proposed solution:

// I propose a new form of object wrapper that holds an object and a
reference to another object
// that will act as that object's prototype. This would be strictly
non-destructive, but allow it to
// be used in place of the original object.

// lets start with a <| example
function customExtend(parent, child){
    //some special modification to child goes here
    return parent <| child;
}
// or my proposed form
function customExtend(parent, child){
    //some special modification to child goes here
    return extends parent child;
}

// This would not currently work with <| and for good reason.
// With the current semantics, setting the _proto_ for child
// could be a BAD thing, and certainly would not work with my intended
// semantics for traits/mixins

// My idea is that instead of directly modifying child's _proto_,
something like a special
// purpose direct proxy were used instead, where all method calls pass
through to the wrapped object,
// but any references to the prototype, or going up the prototype
chain would instead be delegated
// to the wrapper's specified prototype instead. This would also be
what calls to super would refer to,
// as the two are directly related.

// I'm not sure if this would be easy to make efficient. My gut says
it would be more efficient than
// copying object properties, and certainly seems like it would
alleviate the concerns of things like
// copying private members. It would also ensure that in the mixin
example, changes to the mixin would
// be reflected in the child. Not sure if that is a good thing, but
its consistent with prototypal
// inheritance.

// In the common case of a literal RHS, this wrapper could be elided,
and therefore create no
// additional overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111103/336cdb2a/attachment-0001.html>


More information about the es-discuss mailing list