Interesting. One wonders why we keep the silly fiction of naming the
constructor after the class if it is really going to show up in the
class as the `construct` method. It's always bothered me that I have
to write the class name in two places, and fix it in two places if I
change my mind
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?
On 2007-12-20, at 10:10 EST, Lars T Hansen wrote:
> Wiki rot. The construct method is long since obsolete.
>
> The wiki really is wildly out of d
Sorry, but you can't.
Jd
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?
>
> On 2007-12-20, at 10:10 EST, Lars T Hansen wrote:
>
>> Wiki rot. Th
Wiki rot. The construct method is long since obsolete.
The wiki really is wildly out of date in some respects. There is
nothing solid to replace it right now, but reading it can cause severe
confusion...
--lars
On Dec 20, 2007 2:57 PM, P T Withington <[EMAIL PROTECTED]> wrote:
> Interesting.
> 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
___
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 f
I haven't tried this in the RI, but what about:
var sup = super;
sup.apply(this, arguments);
?
Peter
On Dec 20, 2007 6:05 PM, Jeff Dyer <[EMAIL PROTECTED]> 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
Peter Hall wrote:
> I haven't tried this in the RI, but what about:
>
> var sup = super;
> sup.apply(this, arguments);
No, the problem arises from two separate facts:
- constructor invocation is not a function call
- super-constructor chaining is not a function call either
Both of thes
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 pass
On Dec 19, 2007, at 10:05 PM, Peter Michaux wrote:
Let's cut to the chase: what are you worried about?
Curious about the process mostly.
Here's a fresh example:
https://bugzilla.mozilla.org/show_bug.cgi?id=409252
My conclusion is at
https://bugzilla.mozilla.org/show_bug.cgi?id=409252#c5
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
On Dec 20, 2007 11:29 AM, P T Withington <[EMAIL PROTECTED]> 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.
On Dec 20, 2007, at 4:01 PM, Jeff Dyer wrote:
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 thi
13 matches
Mail list logo
