> Your last requirement is the rub. As currently defined,
> prototype: { ...}
> would replace the value of the constructor's 'prototype' property which would
> mess up the implicit constructor/prototype wiring. Defining : to mean .{ if
> the property already exists seems fragile and precludes the possibility of
> using .{ to replace property values. But, what if we allow:
> propName.{ ...}
> to occur in a PropertyAssignment position of an object extension literal.
> Then the pattern could be:
>
> const ClassName = SuperClass <| function(/*constructor parameters */) {
> //constructor body
> super.constructor(/*arguments to super constructor */);
> this.{
> // per-instance properties
> };
> }.{
> prototype.{ // <<<<< note . instead of :
> // methods
> },
> // class (ie, constructor) properties
> };
>
> It's only a one character change but it eliminates the hazard that some
> people are concerned about of leaving off the .constructor or
> .constructor.{...} at the end of the pattern. Also, I can imagine that
> "recursive stache" (hey, it's inevitable that "mustache" will get contracted
> to "stache") would be useful in other situations. Personally, I find this new
> pattern not quite as "pretty" than my original proposal (it's less symmetric/
> more irregular hence probably harder to learn and remember) but I'd still be
> happy to use it.
>
> If we could actually agree to this, then we could move on to making sure that
> the new operator did the right thing for non-function object and then we
> really would have a complete set of primitives that nicely and
> interoperability supported both classical and prototypal inheritance
> abstractions.
I had considered introducing a ..{} operator for this kind of recursive
merging, but your solution is better, it gives you something like generic tree
merging. Pros and cons of this new pattern:
- Con: Not as pretty as your pattern.
- Con: It makes it easier to define class methods than instance methods (the
former being rarer).
- Pro: Better reflects what is actually going on under the hood (where things
just aren’t as symmetric as your pattern suggests). It looks to me like the
prototype turned inside out, as if one could define a callable object literal.
IMHO, the pro outweighs the two cons.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
Home: rauschma.de
Blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
