On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock <[email protected]> wrote:
>
> On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
>
>> ...
>> I can see the "recursive stache" useful in some situations (although
>> it is another syntax addition to object literals). It would allow for
>> the ability to apply a deeply nested "patch" to an object, which is
>> sort of interesting to think about. However, what I think this
>> pattern, the original pattern, and Axel's pattern all lack is that it
>> places too much emphasis on class members, and not enough on the
>> prototype. Perhaps I'm being too nit-picky now, but I find that
>> class/static members are a whole lot more rare than prototype/instance
>> members. My proposal was shooting for a sweet spot where the 90% (a
>> made up number of course) case of a constructor and some prototype
>> methods could be handled in one object literal, effectively the same
>> code as the body of a potential class literal.
>
> The problem with:
>>
>> const ClassName = SuperClass <| {
>> constructor(/*constructor parameters */) {
>> //constructor body
>> super.constructor(/*arguments to super constructor */);
>> this.{
>> //per instance property definitions
>> }
>> }
>> method1(){ return super.method1(); }
>> method2(){}
>> prop1:"Properties unlikely, but allowed"
>> }.{
>> //class properties
>> staticMethod(){}
>> };
>>
>
> Is that the
> SuperClass <| {
> ...
> }
> part evaluates to the prototype object, not the constructor function and
> hence what you would be naming is the prototype. This, in general, is how
> stache has to work for arbitrary object literals where all you really are
> trying to do is set the [[Prototype]]. There really isn't anything special
> in your pattern that distinguishes it from that simple object case.
What distinguishes it is that I was adding a new case to <| operator where the
LHS is a constructor function and the RHS is an object literal. My intention
was that SuperClass would be the constructor function not a prototype. Perhaps
this is confusing because the return type is not the same as the same as the
RHS.
> However, new currently throws when applied to non-function objects. This is
> something I would like to fix for ES.next.
I assume this would be sugar for Object.create with only the first argument? I
think that would be interesting considering JavaScript has optional parens on a
no arg constructor, so the two would look the same - new foo vs new Foo. In a
way, they are practically the same thing. It could be a good way of closing the
gap between pure prototypal inheritance and the simulated class constructor
style. I think both are valuable and it would be really great if they sat well
together in ES.next
- Russ_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
