On Jun 26, 2011, at 11:44 PM, Brendan Eich wrote:
On Jun 26, 2011, at 3:05 PM, Allen Wirfs-Brock wrote:
On Jun 26, 2011, at 8:48 PM, Brendan Eich wrote:
But I still wonder if we wouldn't be better off restricting where super can
occur. I can't prove it, but we are following in the
On Jun 26, 2011, at 10:49 AM, Oliver Hunt wrote:
On Jun 26, 2011, at 9:29 AM, Brendan Eich wrote:
In the languages and systems that have super()-only, a method always has a
name.
So we could define method that can use super narrowly, as the new syntax
in object initialiser, or in class
On Jun 26, 2011, at 10:54 AM, Axel Rauschmayer wrote:
This would only work inside an object literal
or in a method in a class.
(similar to |super|, where you need to know about |here|, the owning object).
Additionally, Allen’s Object.defineMethod already has a parameter with the
method
On Jun 26, 2011, at 3:05 PM, Allen Wirfs-Brock wrote:
On Jun 26, 2011, at 8:48 PM, Brendan Eich wrote:
But I still wonder if we wouldn't be better off restricting where super can
occur. I can't prove it, but we are following in the universal-'this'
footsteps (but with static or else
On Jun 23, 2011, at 11:12 PM, Brendan Eich wrote:
On Jun 23, 2011, at 12:07 PM, Axel Rauschmayer wrote:
...
- Making current function available to a function does not incur costs?
This is *not* an extra parameter, then?
Do you mean current object, aka |here|?
If so, that's an
On Jun 22, 2011, at 4:02 PM, Axel Rauschmayer wrote:
From: Brendan Eich bren...@mozilla.com
Date: June 23, 2011 0:21:17 GMT+02:00
Is there no per-call cost whatsoever to adding static super?
No, it's static -- an internal property of the function object set once on
creation and (in my
On Jun 23, 2011, at 7:04 AM, Brendan Eich wrote:
On Jun 22, 2011, at 4:02 PM, Axel Rauschmayer wrote:
Does the named function expression cost nothing here?
This is entirely beside the point.
Dynamic |super| as Sean proposes requires *every call site* to pass the
|here|
On Jun 23, 2011, at 12:31 PM, Axel Rauschmayer wrote:
This is entirely beside the point.
Dynamic |super| as Sean proposes requires *every call site* to pass the
|here| parameter or something derived from it, no way around that.
Paying for 'super' if you use it, buying by the yard, is
On Thu, Jun 23, 2011 at 4:56 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If you don't have actual implementation experience with dynamic languages I
think you guys will just have to take Brendan's and my word for this.
I now understand and fully agree with your performance arguments
On Jun 23, 2011, at 2:56 PM, Axel Rauschmayer wrote:
- Making current function available to a function does not incur costs?
This is *not* an extra parameter, then?
the current function is made available via the function name in a function
declaration:
var q= -1;
A couple corrections below:
On Thu, Jun 23, 2011 at 9:14 AM, Sean Eagan seaneag...@gmail.com wrote:
When a super delegate function is subsequently accessed from an
object, e.g. o.methodThatUsesSuper or
Object.getOwnPropertyDescriptor(o,
accessorWithGetterOrSetterThatUsesSuper), this resolves
Ok, sorry it took me so long, but I agree that the general idea of
Object.defineMethod is the best solution. I think it can be improved
upon though, by adding the following:
Ability to use any property descriptor attributes when defining methods.
Ability to assign accessor getters and setters as
On Jun 23, 2011, at 12:07 PM, Axel Rauschmayer wrote:
I believe you about the dynamic super. I can summarize my question as
follows:
- Making super or current object available to a function incurs costs.
These are two separate costs. You didn't define which 'super' but from
context I'll
On Jun 23, 2011, at 2:00 PM, Sean Eagan wrote:
Ok, sorry it took me so long, but I agree that the general idea of
Object.defineMethod is the best solution. I think it can be improved
upon though, by adding the following:
Ability to use any property descriptor attributes when defining
On Jun 23, 2011, at 10:39 PM, Axel Rauschmayer wrote:
Related topic: How would |super| be handled if |this| is lexical?
There's no connection, AFAIK. But we also don't have a lexical-this proposal
in Harmony yet.
I would expect problems that are similar to that = this:
var obj = {
On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
One thing I'm not sure about: whether Object.defineMethod should mutate
C.prototype.foo's internal property, or make a new function object with a
different 'super' binding.
I'm still thinking about this but I'm leaning towards specifying
On Jun 22, 2011, at 2:28 AM, Allen Wirfs-Brock wrote:
On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
One thing I'm not sure about: whether Object.defineMethod should mutate
C.prototype.foo's internal property, or make a new function object with a
different 'super' binding.
I'm still
There is no infinite recursion hazard in the semantics that Axel
suggested, and that I used in the gist I posted
(https://gist.github.com/1036200), where |super| is essentially the
the [[Prototype]] internal property of the object on which the method
or accessor getter or setter was found except
On Wed, Jun 22, 2011 at 4:28 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
One thing I'm not sure about: whether Object.defineMethod should mutate
C.prototype.foo's internal property, or make a new function object with a
different
From: Sean Eagan seaneag...@gmail.com
Date: June 22, 2011 15:48:18 GMT+02:00
There is no infinite recursion hazard in the semantics that Axel
suggested, and that I used in the gist I posted
(https://gist.github.com/1036200), where |super| is essentially the
the [[Prototype]] internal
On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
There is no infinite recursion hazard in the semantics that Axel
suggested, ...
Yes, I acknowledged that, but went on to repeat that an extra implicit
parameter is too costly (as opposed to a new internal property of functions).
I don't think
On Wed, Jun 22, 2011 at 9:23 AM, Axel Rauschmayer a...@rauschma.de wrote:
From: Sean Eagan seaneag...@gmail.com
Date: June 22, 2011 15:48:18 GMT+02:00
There is no infinite recursion hazard in the semantics that Axel
suggested, and that I used in the gist I posted
On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
I don't think we need any safety check when assigning a method or
accessor getter or setter that uses super to an object. The concept
of super seems to be a relative one,
On Jun 22, 2011, at 8:28 AM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
I don't think we need any safety check when assigning a method or
accessor getter or setter that uses super to an object.
On Wed, Jun 22, 2011 at 10:35 AM, Brendan Eich bren...@mozilla.com wrote:
Functions have static scope (see the [[Scope]] internal property). This is
absolute and with very good reason!
Yes, functions have static scope, but functions (and all objects) do
not have static owning objects, they are
On Wed, Jun 22, 2011 at 1:01 PM, Sean Eagan seaneag...@gmail.com wrote:
Its value is already resolved via prototype climbing, I don't see the
tremendous cost is simply making this value accessible within the
function activation which occurs as a result of the prototype
climbing.
Can the
On Wed, Jun 22, 2011 at 8:28 AM, Sean Eagan seaneag...@gmail.com wrote:
On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
I don't think we need any safety check when assigning a method or
accessor getter or setter that
On Wed, Jun 22, 2011 at 12:33 PM, Peter Michaux petermich...@gmail.com wrote:
I agree that dynamic this but static super seems odd but maybe
symmetry with this is not desired. Maybe we should have static
super and be looking for symmetry with a static self.
Symmetry with |this| is important
On Jun 22, 2011, at 9:01 AM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 10:35 AM, Brendan Eich bren...@mozilla.com wrote:
Functions have static scope (see the [[Scope]] internal property). This is
absolute and with very good reason!
Yes, functions have static scope, but functions (and all
On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Can the value of a dynamic super be unambiguously resolved with prototype
climbing and without an extra implicit parameter?
Yes, it can be unambiguously
On Wed, Jun 22, 2011 at 3:01 PM, Sean Eagan seaneag...@gmail.com wrote:
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Can the value of a dynamic super be unambiguously resolved with prototype
climbing and without an extra implicit parameter?
Yes, it
On Wed, Jun 22, 2011 at 2:10 PM, Brendan Eich bren...@mozilla.com wrote:
Yes, functions have static scope, but functions (and all objects) do
not have static owning objects,
The scope in ES1-5 can be an object, the global object. Your use of owning
here either covers that case, in which your
On Wed, Jun 22, 2011 at 2:11 PM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Can the value of a dynamic super be unambiguously resolved with prototype
climbing and
On Jun 22, 2011, at 2:36 PM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 2:10 PM, Brendan Eich bren...@mozilla.com wrote:
Yes, functions have static scope, but functions (and all objects) do
not have static owning objects,
The scope in ES1-5 can be an object, the global object. Your use of
On Jun 22, 2011, at 2:37 PM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 2:11 PM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Can the value of a dynamic super be
From: Brendan Eich bren...@mozilla.com
Date: June 23, 2011 0:21:17 GMT+02:00
Is there no per-call cost whatsoever to adding static super?
No, it's static -- an internal property of the function object set once on
creation and (in my view) never changed thereafter unless unobservably
From: Mariusz Nowak medikoo+mozilla@medikoo.com
Date: June 21, 2011 10:54:29 GMT+02:00
From my perspective, this proposal looks perfect. I wouldn't look further :)
I agree. Object literal extensions are all very nice.
Note that (as Brendan mentioned) |here| (which I used to explain
On Sun, Jun 19, 2011 at 2:14 PM, Brendan Eich bren...@mozilla.com wrote:
On Jun 19, 2011, at 10:20 AM, Axel Rauschmayer wrote:
It would be nice if super could work in any method and not just those
methods that are defined inside an object literal. Then, a method would have
to know what object
We wish to avoid another parameter computed potentially differently for each
call. It will cost
What costs do you foresee? I am not sure that there is much to
compute. Assume a method call O.m(). Assume m is found on an
object P within O's protoype chain. This will result in P.m being
On Tue, Jun 21, 2011 at 9:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
We wish to avoid another parameter computed potentially differently for each
call. It will cost
What costs do you foresee? I am not sure that there is much to
compute. Assume a method call O.m(). Assume m is found on
On Jun 21, 2011, at 4:13 PM, Sean Eagan wrote:
On Tue, Jun 21, 2011 at 9:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
We wish to avoid another parameter computed potentially differently for
each
call. It will cost
What costs do you foresee? I am not sure that there is much to
I'm answering some of the performance questions in this, but i don't know what
the intended semantics of 'dynamic super' would be so I can't give specific
details of most of the use cases. If it's essentially sugar for super.foo =
Object.getPrototypeOf(this).foo (with appropriate munging for
On Jun 21, 2011, at 11:53 AM, Brendan Eich wrote:
On Jun 21, 2011, at 11:33 AM, Oliver Hunt wrote:
I'm answering some of the performance questions in this, but i don't know
what the intended semantics of 'dynamic super' would be so I can't give
specific details of most of the use cases.
I actually have a solution in mind for this.
Under the current proposal, a method containing super is statically bound to
a specific object that provides the [[Prototype]] base for the super property
lookup. This is normally done by defining the method in the context of an
object literal or
Brendan Eich-3 wrote:
Quoting from
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super :
When a function contains a reference to super, that function internally
captures an internal reference to the [[Prototype]] of the object created
by the enclosing object
I have also been working on a proposal to extend super to be
available anywhere by using a super binding concept similar to the
exising this binding concept, as well as taking ideas from [object
initialiser super]. It is a work in progress, any comments would be
much appreciated!
Please see:
It doesn't seem quite right that an upward call like
Object.getPrototypeOf(here).foo.call(this)
has sugar
super.foo()
but sideways calls like
here.foo.call(this)
don't have any sugar.
What is the use case for sideways calls? Can you point me to an example? If you
are
Right. Sorry if I added to the confusion. My explanation was along the lines:
“If there is a dynamic |super|, then...”. The lexical |super| is perfectly
adequate.
I’d imagine it would work something like this (modulo some syntactic sugar):
var Super = {};
Super.foo = function() {
return
On Mon, Jun 20, 2011 at 3:23 PM, Axel Rauschmayer a...@rauschma.de wrote:
What is the use case for sideways calls? Can you point me to an example?
You want to allow the API (a.k.a. public methods) of an object to be
overridden, but you don't want the functionality of any non-overidden
API
Exactly!
One way to do this is to give methods an implicit parameter here (the object
in which a method was found during dispatch), in addition to this.
Then
super.foo(x, y)
would desugar to
Object.getPrototypeOf(here).foo.call(this, x, y)
With call() and apply(), you would
On Sun, Jun 19, 2011 at 10:56 AM, Axel Rauschmayer a...@rauschma.de wrote:
Exactly!
One way to do this is to give methods an implicit parameter here (the
object in which a method was found during dispatch), in addition to this.
In some variant, here might make it possible to do what I was
On Jun 19, 2011, at 12:54 PM, Axel Rauschmayer wrote:
Makes sense.
I don’t know how problematic this would be, but if super is an internal
property of a function, then it could be updated whenever such a function is
set as the value of a property.
No, that doesn't work. Both for cases
On Jun 19, 2011, at 7:32 PM, Axel Rauschmayer wrote:
I don’t know how problematic this would be, but if super is an internal
property of a function, then it could be updated whenever such a function
is set as the value of a property.
No, that doesn't work. Both for cases where the
53 matches
Mail list logo
