new instantiation design alternatives

Brendan Eich brendan at mozilla.org
Mon Sep 15 17:10:39 PDT 2014


Allen Wirfs-Brock wrote:
> On Sep 14, 2014, at 9:24 PM, Brendan Eich wrote:
>
>> >> perhaps: >> >> `constructor{a: x, b: y), [a1,a2,a3,...arest], c ) : 
>> super(arguments[0], arguments[1]) {}` >> >> but that means that the 
>> special header form must allow arbitrary expressions. Are those 
>> expression in the parameter scope of the body scope.
>> >  
>> >  You meant "or", I'm sure. Kevin replied "yes" and "yes", which is funny, but either way, parameters are in scope. That's a no-brainer. Why is this a dilemma?
>
> Because, if it is in the parameter scope, rather than the body scope then Kevin's "gimmeSomeComplexSuperArgsYo" function can't be an inner function of the constructor.  It has to be an unencapsualted function outside of the class definition.  If it is in the body scope it is code that physically outside of the { }'s but evaluated as if it was inside the {}'s.

Yeah, as Kevin already noted in his reply, parameter scope is good 
enough. That resolves the hoisting to left of {, as we did for default 
parameters. Right?

Point is, how does this case differ in principal? Just because special 
forms follow the closing ) of the formal parameter list does not mean 
they see the {-delimited-on-the-left scope.

> >  FWIW, I wouldn't want such a thing!
>
> that was just a quick off-the cuff for instance.  I probably wouldn't recommend that particular design either.  But the point is that while "invoke the super class constructor first" is probably the most common use case (that's why I favor the auto-super design alternative) for other use cases you may need to perform arbitrary complex computations before invoking the super class constructor.  And JS is a statement-based  language or arbitrary computation means potentially multiple statements.

This is reductive. JS as stmt/expr-based can rationalize any amount of 
lower-level encoding of what might be better done by higher-level 
special forms. If the proposal has too many degrees of freedom, deal 
with it. Don't just appeal to JS-as-it-is. That is not stable ground 
from which to argue.


>> >  
>> >  Are you sure you've sorted use-cases by use-frequency?
>
> I didn't claim they were.  In the gist, the use cases are roughly ordered by increasing complexity and secondarily by likely use-case frequency.

Sort the other way. It'll be illuminating if not decisive.


>>> >>  The constrained super expression is a slippery slope that leads you to a cliff. Better to go with the full generality and expressiveness of the function body.
>> >  
>> >  You need to demonstrate this, instead of assuming it.
>
> It's certainly something I've encountered many times.  And it's just a special of the general pattern of a method doing a super-call to the method it over-rides.  Sometimes you want to do a super call first ( "after" in AOP or Lisp parlance), sometimes you want to do the super call at the end (a "before" wrapper) and sometimes you want to do it in the middle ("around").  Lots of examples of all of these exist in real world code.

The design biases by default (implicit) and brevity toward one or 
another. It does not equate all of those. The issue I'm flagging is 
mainly what should be the default, but also whether we want special 
(form) syntax instead of verbose imperative boilerplate. Two separate 
considerations!


>>> >>  It's this explicitness that grows on you.  The code actually says what it means.
>> >  
>> >  Classes as sugar, not as salt. The way this is headed, people will go back to functions. I'm not kidding.
>
> I have to respectfully disagree with this unprovable conjecture.

It's not conjecture, it is a hypothesis. We'll find out, at least if we 
stick to the championed course. However:

> But feel free to propose and champion a complete alternative propos that address all aspects of object instantiation design. That's probably a better approach than trying to incrementally change details of a coherent design until it is something completely different.

Nope, you haven't got TC39 consensus, or near that, yet. So playing a 
"champion a different proposal" power move is risky, and makes it look 
like you can't adapt from championed (but not use-case-frequency-sorted) 
proposal to something *even better*.

As Kevin wrote in his reply, we are (via dialectics, discussion) trying 
to improve on the championed straw man. So jumping to "my way or the 
high way" is unjustified, risky, and kind of crappy. Please regroup! 
I'll gladly endorse the championed proposal if you actually *deal with 
substantive feedback*.

/be
>
> Allen
>
>
>


More information about the es-discuss mailing list