On Jun 20, 2011, at 7:40 PM, Brendan Eich wrote:
On Jun 20, 2011, at 11:17 AM, Mark S. Miller wrote:
Wow, good catch. That's an oversight -- I don't remember this case being
noticed when we discussed this issue. I agree with your conclusion on three
grounds:
I remember this, or at
On Jun 21, 2011, at 12:50 AM, Luke Hoban wrote:
My read of the spec is that thi\u0073 is a ReservedWord and should not be
allowed as an Identifer. So the following part of the examples quoted below
should be an early error:
var thi\u0073 = 42;
The text in 7.6 seems to address this
rauschma wrote:
var c1 = Object.create(C);
obj.one(); // 'A.foo'
That would be c1.one(), right?
Yes, sorry edited post twice.
rauschma wrote:
|here| === C and thus the search for super.one starts in B and finds
A.one.
B.two = function () {
this.three();
};
B.three
On 21/06/11 00:50, Luke Hoban wrote:
My read of the spec is that thi\u0073 is a ReservedWord and should not be
allowed as an Identifer. So the following part of the examples quoted below
should be an early error:
var thi\u0073 = 42;
The text in 7.6 seems to address this with:
All
Do we really need the dynamic this arrow -, or can we make do with just
the lexical this arrow =.
Are functions that depend on dynamic |this| ever *not* methods?
Sure. The main use-case is constructors (and you can make a function do
double-duty, as a constructor or a function called
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
Hi,
I've recently seen the slides of Dave Mandelin Know your engine - How
to make your JavaScript fast [1]. If I understand slide 121 correctly,
then a type inference engine can know in some cases if all elements of a
(dense?) array have the same type.
On the Harmony proxies proposal, one
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
As a loose analog to the prototype-chain-traversing getPropertyDescriptor(), I
would still like to have something that allows one to easily *change*
properties higher up the prototype chain (e.g. to use a prototype to share
state).
Maybe it would be enough to just have
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
2011/6/21 Allen Wirfs-Brock al...@wirfs-brock.com:
ES5.1:
7.6.1 Reserved Words
A reserved word is an IdentifierName that cannot be used as an Identifier.
7.6 Identifier Names and Identifiers
Identifier Names are tokens that are interpreted according to the grammar
given in the
On Jun 21, 2011, at 2:18 AM, Axel Rauschmayer wrote:
Do we really need the dynamic this arrow -, or can we make do with just
the lexical this arrow =.
Are functions that depend on dynamic |this| ever *not* methods?
Sure. The main use-case is constructors (and you can make a function do
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
This would make things easier to understand. When I explain this aspect of
JavaScript to others, they are often stumped, but I have never encountered
anyone who was confused by Python:
class MyClass:
def mymethod(self):
return hello world
def myfunction():
return hello
2011/6/21 Mike Samuel mikesam...@gmail.com:
In that case, we still have at least 3 (haven't tested IE) of 4 major
browsers agreeing that the illegal EcmaScript program
this.\u0069\u0066 = function () { alert(called \u0069\u0066); };
\u0069\u0066(false)
alert(1);
should be
I think some engines just have a bug to fix here, nothing more. :-/
/be
On Jun 21, 2011, at 11:48 AM, Mike Samuel wrote:
2011/6/21 Mike Samuel mikesam...@gmail.com:
In that case, we still have at least 3 (haven't tested IE) of 4 major
browsers agreeing that the illegal EcmaScript program
Yes, you made a nice case. In a way I'm glad, as I wasn't too keen on the
additional complexity brought about by the bicephal approach (membranes
could still be made to work by converting all non-configurable properties
into accessors as shown on the wiki page, at the price of giving up fully
On Jun 21, 2011, at 8:24 AM, Axel Rauschmayer wrote:
As a loose analog to the prototype-chain-traversing getPropertyDescriptor(),
I would still like to have something that allows one to easily *change*
properties higher up the prototype chain (e.g. to use a prototype to share
state).
Such
That sounds like the opposite argument you are making with regard to the
hypothetical |here|:
BTW I do not agree we can or should try to reserve 'here' or expose the
method's home object -- that breaks abstractions built using prototypes.
'super' does not, because it always goes to the
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.
On Jun 21, 2011, at 1:50 PM, Axel Rauschmayer wrote:
That sounds like the opposite argument you are making with regard to the
hypothetical |here|:
BTW I do not agree we can or should try to reserve 'here' or expose the
method's home object -- that breaks abstractions built using
23 matches
Mail list logo
