super.apply(this, arguments)

Jeff Dyer jodyer at adobe.com
Thu Dec 20 16:01:59 PST 2007




On 12/20/07 11:29 AM, P T Withington wrote:

> Given that we already have a whacky syntax for calling the super
> initializer (which I confess I had forgotten), why not allow apply
> there?  It's unambiguous there, since you are only allowed to call the
> super initializer.  This syntax is just letting you override how your
> arguments are passed on to your super initializer.

The only problem I see is that the syntax 'super . apply ( )" looks a lot
like a super expression, which has a different meaning than what you want it
to mean. Not a deal breaker, but an usability check.

> What is the  
> default if I don't specify a call to my super initializer?  Does it
> get all my arguments, or none of them?

None of them.

> 
>    class A extends B {
>       function A(x,y,z) : super.apply (this, arguments) { ... }
>    }
> 
> ?

The original Netscape ES4 proposal had syntax for passing arguments as an
array. (Waldemar are you listening?) IIRC it used triple dots like this:

   foo(...args)

to mean use the elements of 'args' as positional arguments of foo. We
dropped this from AS3 for lack of evidence for its need. But this might be a
way forward.

   class A extends B {
      function A(x,y,z) : super(...arguments) { }
   }

> 
> Personally, I really don't like the magic of the class name naming the
> initializer.  I would rather see a magic method name, say
> `initialize`, so you say:
> 
>    class A extends B {
>       function initialize(x,y,z) {
>         super.initialize.apply(this, arguments);
>         ...
>       }
>    }
> 
> but that is probably too radical.  On the plus side, you don't have to
> repeat the class name, which makes easier maintenance and code reuse,
> on the minus side there is a magic method name and you have to decide
> whether to enforce arglist congruency or not (an issue hidden by
> having each initializer have the class name as its name).

During the development of AS3 we considered other naming schemes for class
constructors. In the end we chose the status quo because it is familiar
(least surprise) and constructors really aren't methods that can be called
directly. They are blocks of code that get executed in conjunction with the
new operation. Making them look like methods seems misleading, at least in
this language.

Jd

> 
> On 2007-12-20, at 13:05 EST, Jeff Dyer wrote:
> 
>> Sorry, I didn't mean to sound so flippant.
>> 
>> As you may know, super expressions limit the binding of the name
>> after the
>> dot to the base class bindings. So the fragment above would call the
>> super
>> instance method 'apply', not the super constructor. We could give
>> 'apply'
>> some special meaning when the first argument is 'this', but the super
>> constructor will have already been called during initialization.
>> 
>> None of this means that the desired semantics wouldn't be possible to
>> achieve with another syntax. My guess is that it would be somehow
>> similar to
>> the current super initializer syntax, which looks like this:
>> 
>>   class A extends B {
>>      function A(x,y,z) : super (x,y,z) { }
>>   }
>> 
>> Suggestion welcomed.
>> 
>> Jd
>> 
>> On 12/20/07 9:04 AM, Dean Edwards wrote:
>> 
>>>> On 12/20/07 7:20 AM, P T Withington wrote:
>>>> 
>>>>> Ok.  I didn't look in the wiki to start with because of that,
>>>>> hence I
>>>>> ask on the list:  can I apply my super's constructor as in the
>>>>> subject
>>>>> line?
>>>>> 
>>> Jeff Dyer wrote:
>>>> Sorry, but you can't.
>>>> 
>>> 
>>> That's a shame.
>>> 
>>> -dean
>> 
> 




More information about the Es4-discuss mailing list