current proposal here, to give JavaScripters
a first impression:
http://www.2ality.com/2011/03/first-look-at-upcoming-javascript.html
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
uring syntax, where this:
>
> let {draw: drawShape} = ... some expression ...;
>
> also binds the identifier |drawShape|.
Got it. Makes sense.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
__
. Object.create() feels like a good start. I’ve tried my
hand at a purely prototypal API, but I find it difficult to make the syntax as
beautiful as plain object literals.
http://www.2ality.com/2011/01/going-completely-prototypal-in.html
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
introduce the concept of classes in JavaScript.
[1]
http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_class_abstraction
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss ma
sion ...;
>>>
>>> also binds the identifier |drawShape|.
>>
>> FWIW, I read these destructuring patterns backwards too. Must be a
>> left/right brain thing. Something I will have to learn the hard way to make
>> it sti
irst-class values, they are represented as
> objects. The body of a module acts as the object's constructor. Binding the
> module object as |this| fits naturally with the design.
>
>> But it seems like the only globals inside a module are module-relative. Then
&
t; We have some support for this on TC39 but it keeps dropping off the radar.
> Comments welcome.
>
> /be
>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I'm not sure how this would be done best or how useful it would be, but: has
dependency injection been considered as a use case for modules (e.g. to swap
modules during testing)?
One possibility might be to give modules parameters that module clients have to
provide.
Axel
--
Dr.
other, e.g. global,
reference).
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
obj = Object.getPrototypeOf(obj);
>return obj;
> }
>
> On Apr 10, 2011, at 10:24 AM, Axel Rauschmayer wrote:
>
>> As far as I am aware, there is no way to change a property that isn’t at the
>> beginning of the property chain, because the change will create a new
>>
to the object that actually owns a given property and then set it there.
Thanks,
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
IRC, {} creates a new instance for each invocation. Thus, a better solution
would be
while (!Object.prototype.hasOwnProperty.call(obj, key))
But I usually prefer David’s more readable version and take the risk of a name
clash.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rausc
s to get much more complicated. When you make modules
> more complicated to use, people don't use them.
Yes, I’m all for simplicity.
> Module loaders do give you the ability to do dependency injection, though, by
> changing the semantics of module URL's.
Right. This should gi
t changing the semantics
> of module URLs means? DI is an important issue and I'd like to
> understand how it is intended to be achieved in the future module
> system.
>>> Module loaders do give you the ability to do dependency injection, though,
>>> by
in strict
mode and in non-strict mode, as explained in the comment.
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.
#x27;t be fixed any more, there could be a method Object.toObject()
with more obvious semantics. I try to avoid "expert magic" when using a
programming language and it seems like a shame that this kind of magic is
necessary here ( {} and valueOf()).
Greetings,
Axel
--
Dr. Axel Rauschmayer
a.
nction f() {
console.log(foo);
}
f();
}
Any confirmations are highly appreciated.
Greetings,
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
FWIW: I’ve written down my understanding of the differences between
LexicalEnvironment and VariableEnvironment in ECMA-262:
http://www.2ality.com/2011/04/ecmascript-5-spec-lexicalenvironment.html
Greetings,
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home
Would it make sense to standardize more exception/error types, for example to
add a MissingParameterError in ES.next?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es
. This idea is mainly motivated
by Java having several predefined exceptions with descriptive names that are
easy to reuse.
With JavaScript, is throwing a string considered bad style (now or in the
future)? That is, is throwing a new Error(msg) better than throwing msg
directly?
Axel
--
Dr
er to current syntactic
style). Is the backslash already taken?
\(x,y) x + y
#\(x) x +y // frozen
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
it be better to use "->" for functions ("lighter", no |this| except
for lexical access to |this|) and "=>" for methods ("heavier", |this| as an
implicit parameter). Or does that deviate too much from current ES semantics?
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
public poll, either (you must have
noticed the variety of opinions on this list alone!). Someone has to make the
hard decisions: Fred Brooks says that (the core of) good design can only be
done by a team of one (two if one of them is dominant).
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
hod.
Isn’t (1) a better solution? I’m assuming (2) is done, because (1) would be too
radical a change (execution contexts etc.)? (1) could be simulated by always
binding |this| in non-method functions, but that isn’t done because of
performance issues(?)
Thanks!
Axel
--
Dr. Axel Rauschmayer
rty of an object) is not declared or even expressed nearby. How would
> you forbid such functions to use |this|, or allow them to but forbid others
> that are not called as methods to use |this|/
See above.
Greetings,
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
hat you mean by “methods”?
>
> The arrow proposal changes nothing by default, it just provides sugar. If you
> are nesting an arrow in another function and want to inherit the outer
> function's |this|, use =>. Else use ->, or perhaps an explicit (this = ...)
> parame
at is not invoked as method. Right now, the same kind of
>> construct is used for both true functions and methods. I’m proposing a new
>> construct (similar to the distinction that Python makes): a function that
>> does not have an implicit |this| parameter.
>
> Hm, y
ust passes that object reference through to the
> call. The method call then uses the base object of the object reference,
> which is |obj|, as the |this|-binding.
Thanks for explaining the details. With "temporary result", I meant what you
call "object reference". Simila
ctually want to program in it. This is
difficult enough, given all the parties that have to be pleased. Listening to
feedback from compiler writers should be a secondary goal.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
b
yntactic sugar for constructor functions
etc.) would maybe not be needed. Still missing is convenient subtyping
The remaining missing functionality is subtyping, but that could be added as an
API (let me know if I should give an example, it would look a lot like YUI, but
with less impedance
// Subtype
function Worker(name, title) {
Person.call(this, name);
this.title = title;
}
Worker.prototype = Object.create(Person.prototype);
Worker.prototype.describe = function() {
return Person.prototype.describe.call(this)+" ("+this.title+")";
};
--
Dr. Ax
for functions)?
Thus: are blocks completely different from functions or are they translated to
the same construct (internally). I can imagine this being done to make
|arguments| lexical, but it seems tricky for handling lexical |this|.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rausc
eason to provide a concise syntax for specifying enumerability.
I would prefer something like
var foo = {
{ !conf !enum !write } high_integrity: 42,
...
};
Yes, it is more verbose, but also more descriptive.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschm
avid Ungar, Craig Chambers, Bay-Wei
Chang, and Urs Hölzle.
http://selflanguage.org/documentation/published/organizing-programs.html
The challenge with prototypal inheritance in JavaScript is to get it right. But
with a little syntactic sugar that wouldn’t be an issue.
--
Dr. Axel Raus
like identifier names are accessible to quasi
handlers, which would make this difficult.
BTW: “Desugaring” at the beginning of “Semantics” seems mangled.
[1] http://api.jquery.com/template
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
know what Brendan meant in this txjs talk with “Classes made it
(Yay, I think? Why am I sad?)”? Is he ambivalent about the proposal? Is there
anything he doesn’t like?
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
e different namespaces explicit:
class Point {
constructor(x, y) {
private @x = x;
private @y = y;
}
equals(p) { return this.@x === p.@x && this.@y === p.@y; }
...
}
Maybe something like the following would work, too:
private.x = x;
...
return this.private.x === p.pr
rhaps not) seems like a mistake.
Terminology-wise, I have always avoided the word “class” in JavaScript and used
the word “type”, instead (with, roughly, constructors implementing types). I
call Properties such as Math.PI type variables. Then you can also talk about
subtyping (instead of subcla
he above obviously profits from anything offered by concise object literals
(and in fact already uses the more compact way to write methods).
I hope this makes sense. A side benefit would be that type/class variables
(such as Math.PI) would automatically be inherited to subtypes/subclasses.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ed to its super-constructor.
Well, this might be a largely academic discussion and class literals are
probably a good enough compromise. But class literals being so similar to
object literals, I like the idea of making do with just concise object literals
and a proto operator.
Axel
--
Dr. A
type is C.
- Invoke o.construct(x,y)
Maybe "initialize" would be a better name than "construct", then.
Couldn’t that illusion be turned into how things are actually done?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home:
s two constructs in
JavaScript: (1) the constructor produces and initializes instances, (2) the
prototype contains shared data.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss m
e P, as used in self, does seem to frequently subsume the role of
>> a class. A constructor generally corresponds to the copy method of such a
>> prototype.
>
> Having thought about this a bit more, I'm beginning to think that perhaps we
> could get by without the pro
tor to be applied to any object so feel free
> to take credit.
I do agree that this beats inventing a new protocol. Very clever.
On Jun 15, 2011, at 8:35 , Brendan Eich wrote:
> On Jun 14, 2011, at 11:25 PM, Axel Rauschmayer wrote:
>
>> Cool! That’s what I meant when
sh and it has a method cm()).
Furthermore, it would automatically be inherited:
const SkinnedMeshExtended = SkinnedMesh <| { ... }
Then the following class method could also be called:
SkinnedMeshExtended.cm()
Right?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.d
more Java-like, where all static methods can also be accessed via instances
(albeit most IDEs give you a warning nowadays, but it’s legal in the language).
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
f (key,value) pairs, then going beyond simple identifiers
would be easy. I am assuming that order matters, if not, then there is
something fundamental about handler parameters that I haven’t understood.
Using jQuery templates to validate template support: good choice, I really like
this templati
"", escaped: "" }, // not really necessary, any more
{ value: 123, key: "baz" },
{ raw: "", escaped: "" } // not really necessary, any more
]);
Alternatively, one could have two different types, one for literal parts, one
for substitut
at makes sense. The ID then allows one to do caching. But I don’t see how the
same quasi-literal can be “invoked” multiple times.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss m
Right, I feel stupid: Even though the literal does not really exist as a
reified construct (separate from code), the corresponding code can be executed
multiple times.
On Jun 15, 2011, at 18:04 , Mark S. Miller wrote:
>
>
> On Wed, Jun 15, 2011 at 8:36 AM, Axel Rauschmayer wrote
he proposal needs to say this a bit more explicitly, and up front.
>
> Added http://wiki.ecmascript.org/doku.php?id=harmony:quasis#callsiteid
> and renamed rawLP and unescapedLP.
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
rs are the necessarily
> >> variable, evaluated-at-runtime substitution expression results.
> >>
> >> The proposal needs to say this a bit more explicitly, and up front.
> >
> > Added http://wiki.ecmascript.
must have a solution in mind that works.
I would expect templating (however it is implemented) to be a frequent use
case, given how many templating engines are out there and given how elegant a
solution quasi-literals are.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitte
Sorry, I just meant the acronym: what does it stand for?
On Jun 16, 2011, at 2:49 , Mike Samuel wrote:
> 2011/6/15 Axel Rauschmayer :
>> Quick feedback: I haven’t seen SVE (substitution value expression?) defined
>> anywhere and can’t find a description of using ${{var}} as
t 5:36 PM, Allen Wirfs-Brock
> wrote:
>
> On Jun 15, 2011, at 4:43 PM, Mark S. Miller wrote:
>
>>
>>
>> On Wed, Jun 15, 2011 at 4:42 PM, Axel Rauschmayer wrote:
>> Ah, very clever. It’d be nice to have an example of using this to compile
>> te
comes:
out.push(token instanceof LiteralSection ? token.raw :
substArray[token.valueIndex]);
This is bike-shedding, but I’d also prefer "uninterpreted" and "interpreted"
instead of "raw" and "cooked".
--
Dr. Axel Rauschmayer
a...@rauschma.de
!
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
above solution is better, because the desugaring is local.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ructs in the template use-case.
Yes, useful. I assume that if the expression is not assignable, trying to use
the function as a setter will produce an exception(?)
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
Syntax error (in some cases)?
On Jun 17, 2011, at 21:38 , Mark S. Miller wrote:
>
>
> On Fri, Jun 17, 2011 at 12:18 PM, Mike Samuel wrote:
> 2011/6/17 Axel Rauschmayer :
> > and redefines the SVE of ${=x.y} to be
> >
> > function () { return arguments.lengt
rand is an object
> that is not a function (alternative, we could give every object created using
> an object literal a [[Construct]] internal method that invokes the
> constructor method, its really just an alternative way to specify the same
> thin
h;
Now the following works (without a separate protocol):
> var sm = new SkinnedMesh.constructor(...);
A next step would be the syntactic sugar suggested by Allen:
new SkinnedMesh(...) => new SkinnedMesh.constructor(...)
However: THREE.Mesh would have to refer to the prototype (similar
or.
- o instanceof C: treat non-function operands differently. Then simply desugars
to C.isPrototypeOf(o).
- new C(): treat non-function operands differently. After construction, things
have to look similar to what they look like today. I don’t think it necessarily
matters how to get there.
-
wing
assignment?
f.prototype = o
I have no trouble understanding that everything (modulo builtins) works fine if
the above assignment is made *somewhere*.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
__
instanceof C means “look for C in the prototype
chain of o”. IMHO that would make things much easier to understand for newbies.
Right now, JS inheritance is hard to understand and hard to explain (especially
subclassing). With “prototypes as classes”, a proto operator (such as <|) an
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 it resides in, e.g. via an implicit parameter.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/raus
d apply(), you would have here === this.
Axel
On Jun 19, 2011, at 19:44 , Peter Michaux wrote:
> On Sun, 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
/ "Alpha.one Beta.one Beta.one"
Would work. The search for super.one() would start in Alpha.prototype, the
search for here.one() would start in Beta.prototype, the search four this.one()
would also start in Beta.prototype.
> g.two(); // "Alpha.one Beta.one Gamma.one"
ially if a literal is long (easier rearrangement of methods, because there
is no need to avoid the trailing comma; context is clearer).
Axel
On Jun 19, 2011, at 21:14 , Brendan Eich wrote:
> On Jun 19, 2011, at 10:20 AM, Axel Rauschmayer wrote:
>
>> It would be nice if "super"
expressed in an
> object initialiser, I'd like to see the exact use-case.
The only use case would be assigning a function that uses "super" to a property.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
nd then add
properties via assignment, to avoid the verbosity of property descriptors).
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ot;
> property as part of an object literal. However, such things could still be
> wired up manually (most likely by somebody wanting to create procedural
> abstractions for class-like definitions.
Are you thinking along the lines of the following example?
var MyClass = class({
and can’t think of any use cases)
=== Example ===
var Multiplier = {
FACTOR :: { value: 3, writable: false },
multiply: function (x) {
return x * this.FACTOR;
}
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog:
.
>> super.update();
>> }
>> }
> the "constructor" function defined above would be automatically created with
> a "prototype" property whose value is the containing object created by the
> object literal. Put another way:
>
le and non-writable. That would be the analog to const for
variables. Via decorators, one could introduce @const for this purpose.
Axel
On Jun 20, 2011, at 18:22 , Brendan Eich wrote:
> On Jun 20, 2011, at 3:43 AM, Axel Rauschmayer wrote:
>
>> Would it make sense to include a
t’s quasis, then ES.next might even be at the center of a
triangle (Java, Smalltalk, Lisp) – which is a good thing.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-dis
essage")},
toString() {return "d "+super.toString()},
];
Rationale
- Does enumerability ever matter?
- Passing the getter through to the super-class seems like a rare use case.
Doing so manually could be optimized by a compiler and while it is a tiny bit
verbose,
> };
> C.two = function () {
> super.two();
> };
> C.three = function () {
> return 'C.three';
> };
>
> var c2 = Object.create(C);
> c2.two(); // C.three
|here| === C and thus super.two === B.two
B.two() uses the original and unchanged |this| whi
I framed things in terms of |here|, because that value can be easily produced,
as a byproduct of looking for a property. It might also, some day, give us the
ability to *set* a property that is not at the beginning of a property chain.
For now, programmers would never directly see |here|, only
amic as proposed in
> http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super. Even
> in Allen's recent post about Object.defineMethod, 'super' is not bound
> dynamically per call site, as 'this' is. It's a hidden property of the
> functi
> The florin works no better than Greek lower-case lambda. Both are already
> legal ES3-5.1 Identifiers and cannot be retasked as keywords, especially not
> with the name of the function in a function expression optional.
Ah, damn, I knew it was a very convincing argument. ;-)
There is s
tinction introduced by block lambdas too much:
- dynamic this --> existing functions and methods
- lexical this --> new, more compact construct, mainly used as the argument of
functions and methods.
This distinction works well as a rule of thumb and keeps things easy to explain.
--
Dr. Axel Ra
dapted to pass in |this|
plus property name plus value for properties and be used for all kinds of
things.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozil
; This distinction works well as a rule of thumb and keeps things easy to
>> explain.
>
> It's not that simple: existing functions can and do use various binding hacks
> to make |this| or a substitute "lexical". Anyway, functions have |this|
> parameters, whether
ngs) would
be a static value, not a dynamic one (unlike |this|). Or (a static) |super|
might just be used directly.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-di
]
- Non-method function that uses super: "here" is undefined, using super causes
an error.
If super is not used there is little computational cost! (Other than a binding
per function call which may still be prohibitive.)
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/raus
(obj, propName):
http://www.mail-archive.com/es-discuss@mozilla.org/msg06652.html
But I can also imagine syntactic sugar:
obj.foo := "abc"
desugars to
Object.getDefiningObject(obj, "foo").foo = "abc"
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.c
he long
> form for all the dynamic this cases that can't be written using
> method-in-initialiser syntax.
Agreed. If a simplification could be done naturally, that would be great. But
as that seems impossible, forcing things does not make sense.
--
Dr. Axel Rauschmayer
a...@rausc
y?
I find that Common Lisp does this well, via "places":
- Property lookup => returns a place, e.g. a pair (object, property name)
- Use the place to either read the property value or to change it.
Can’t comment on Proxies, though.
On Jun 21, 2011, at 21:36 , Brendan Eich wrote:
>
eas
"here" can point to any of its members. E.g. when you invoke
var s = new String("abc");
s.trim();
then "here" === String.prototype, but "this" === s. Otherwise
String.prototype.trim() could not access the properties of s (such as s.le
va was to define constants and collect
all values at the same time:
const red = new Color("FF");
const green = new Color("00FF00");
Color.prototype.getAllColors().forEach(...);
But you could also produce the colors with a factory.
--
Dr. Axel Rauschmayer
a...@rauschma.d
atic super to work as follows:
var Sub = Super <| {
foo: function me(x) {
me.super.foo.call(this, x);
}
}
Does the named function expression cost nothing here?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
a big problem.
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.
- Making "current function" available to a function does not incur costs? This
is *not* an extra para
wrote:
>
> On Jun 21, 2011, at 9: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
;this") will also take me to a class
variable (also via "this"). If I invoke the method via "this", e.g.
Array.prototype.myClassMethod(), then this.myClassVariable would *still* work.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2
etter naturally do the same thing for getters, you have
> your way to change a value "directly on the prototype chain".
> Of course, if you want to change the property descriptor on the prototype
> chain, none of what I said apply.
>
> David
>
>
> Le 21/06
how lexically scoped access is
> implemented)
Isn’t "bar" a named function expression and won't this binding be local to the
expression (unlike q)? But I don’t think that changes the cost.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog:
t |thisFunction| would
also incur costs, but Allen has since said that these costs are negligible.
Related topic: How would |super| be handled if |this| is lexical?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
rr) {
arr.forEach(function(x) {
super.mymethod(x); // would this work?
});
}
}
Thankfully, I don’t think that super-calls will be very common in typical
JavaScript code, in contrast to "this".
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
t; introduce multiple special forms that can introduce a this-rebinding
> boundary, where the new ones are easily missed, we make this burden worse. Is
> "->" easily missed? (I would guess so.) And if it is, what are we getting in
> exchange, and is it worth it?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
1 - 100 of 582 matches
Mail list logo
