Is 'super' currently limited to method bodies, excluding local functions?
Given that 'this' is lexical in arrow functions, I expected any enclosing
'super' to be available, as well, but I cannot confirm this from the spec.
Yes, clearly super should be able to be used in an arrow function that
That's related to a feature I have on my list to implement:
cross-referencing actions in a step-through debugger/action record with
their specific origin in the spec. So as you step into a function, see a
sidebar scrolling by with Function Declaration Instantiation, multiple hits
on
Recall the main objection was not the generativity of @names mixed with the obj.@foo pun
(after-dot). It was the usability tax of having to declare
private @foo;
before defining/assiging
obj.@foo = foo;
(in a constructor, typically).
Good clarification, thanks. Yes, the more important
On Dec 4, 2012 4:59 AM, Claus Reinke claus.rei...@talk21.com wrote:
ES, for all its faults, has a spec on the formal side -which is a very
good thing!- but unfortunately also on the not directly readable side.
The reason is that the spec is essentially a reference implementation -
even
Allen Wirfs-Brock wrote:
On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:
On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
The simplification I've thought about is eliminating [[Construct]]
as an internal method/Proxy
On 4 December 2012 14:28, Claus Reinke claus.rei...@talk21.com wrote:
Could you please document the current state of concerns, pros and
cons that have emerged from your discussions so far? You don't
want to have to search for these useful clarifications when this topic
comes up again (be it in
On Mon, Dec 3, 2012 at 6:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
OK, so it sounds like we have a plan. I'll update the spec. to use
@@create.
Thanks for resolving this. Having the class side inheritance for @@create
makes complete sense to me and it solves a lot of issues. It
Is there a missing step in that outlined algorithm? Where is [[Prototype]]
set?
So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo). //Foo is passed as the this value to
@@create
2.5) Call
Claus Reinke wrote:
Like everyone else on this list, I have grown familiar with the current
spec - not as familiar as tc39 members, but enough to find answers
to questions when I need them.
But with the evolving drafts of the new spec, I'm back in the situation
most JS coders are wrt the
Herby Vojčík wrote:
WHY / WHAT / HOW sections (with only HOW being normative)?
I've said it before: ECMA-357 (E4X) tried this and all it did was make
more bug habitat in the informative sections, and confuse implementors
who treated prose as normative and took its differences not as bugs,
Andreas Rossberg wrote:
Indeed. (Although I don't think we have implicit let-scopes in JS.)
Only in comprehensions and generator expressions, which have an explicit
outer syntax.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
On Tuesday, December 4, 2012 at 8:34 AM, Sam Tobin-Hochstadt wrote:
Language specification is a difficult task, especially when handling a
complex language, legacy spec style, and wide variety of audience background,
not to mention a committee with lots of feedback and opinions. We are
=== @names ===
I think punting on @name syntax until ES7 is a wise move. I would like to
sneak in a word of clarification on my modular @name proposal, though. In
my proposal, @names are not implicitly declared variables. They are
namespaced identifiers, where the namespace container is the
Kevin Smith wrote:
=== @names ===
I think punting on @name syntax until ES7 is a wise move. I would like
to sneak in a word of clarification on my modular @name proposal,
though. In my proposal, @names are not implicitly declared variables.
They are namespaced identifiers, where the
On Dec 4, 2012, at 5:37 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo). //Foo is passed as the this value
to @@create
3) Let
On Dec 4, 2012, at 7:21 AM, Erik Arvidsson wrote:
Is there a missing step in that outlined algorithm? Where is [[Prototype]]
set?
So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo). //Foo is
There is a long history of people publishing annotated versions of language
standards that add informative materials. The Ecma copyright even explicitly
allows for this.
I think I've said before that there is an opportunity here for somebody to run
with this idea for ECMAScript. You don't
(Note that this is probably the sort of issue that would be better to report to
bugs.ecmascript.org)
Yes, that looks like an issue. It appears to me that the best fix is in the
evaluation semantics of FunctionBody. It should take care of Return
completions and also make sure that normal
On Dec 3, 2012, at 2:53 PM, Nathan Wall wrote:
I'm not a person of influence, but as a JS developer, I agree with Andrea on
this. I think Map#set() should return the value. I would expect the same
behavior as obj[key] = value. I find Andrea's use case (m.get(k) || m.set(k,
v)) more
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is
the simple, backwards-compatible path. Strict mode only has a bad
reputation because, in ES5, it is restrictive-only. There are
(almost) no carrots leading users there.
Strict mode has a bad rep for two
Allen Wirfs-Brock wrote:
On Dec 4, 2012, at 5:37 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo). //Foo is passed as the this value
to
clear for us ( Developers ) but also clear semantically speaking.
As it is proposed now it looks like if a setter returns something which
is the context while, again, when you set 99% of the time you don't want to
do it separately in order to have that value back.
You don't want to create
On Tue, Dec 4, 2012 at 12:42 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
If you forget to do the super[create] call you don't get [[Prototype]]
initialized. However, if you leave out that super call you will also not
allocate any superclass provided per instance state. So, it would
Allen Wirfs-Brock wrote:
It's less clear which is the best choice for JS.
I have to say I think Mark is on the better track (not to say only
right track). Cascading wants its own special form, e.g., Dave's
mustache-repurposed proposal at
Thanks.
I've just filed it to bugs.ecmascript.org
https://bugs.ecmascript.org/show_bug.cgi?id=1119
It appears to me that the best fix is in the evaluation semantics of
FunctionBody.
Looks nice to me too.
On Wed, Dec 5, 2012 at 3:15 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
(Note
On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens math...@qiwi.be wrote:
On 30 Nov 2012, at 22:50, Norbert Lindenberg
ecmascr...@norbertlindenberg.com wrote:
There's nothing in the proposal yet because I intentionally kept it
small. It's always possible to add functionality, but we need some
1JS wants new syntax to be its own opt-in.
Right - except of course `let[i] = j;` isn't new syntax. In non-strict,
`let` is either an identifier, or it isn't. If it's an identifier, then
let it be a full-fledged identifier, not some half-man, half-beast. I
think it's best to avoid situations
On Dec 4, 2012, at 10:57 AM, Erik Arvidsson wrote:
On Tue, Dec 4, 2012 at 12:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
If you forget to do the super[create] call you don't get [[Prototype]]
initialized. However, if you leave out that super call you will also not
On Dec 4, 2012, at 8:54 AM, Kevin Smith khs4...@gmail.com wrote:
Particularly worrisome to me is the suggestion that the default loading
behavior should map:
import x from foo;
to:
System.baseURL + foo + .js
This is contrary to all url resolution algorithms on the web, and
In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also
13.2.2 [[Construct]], which layers on [[Call]], so [[Call]] is the
lowest layer single algorithm that has to deal with completions.
Pushing down into FunctionBody is ok if there are no other uses of
FunctionBody that do
On Tue, Dec 4, 2012 at 1:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
clear for us ( Developers ) but also clear semantically speaking.
As it is proposed now it looks like if a setter returns something which
is the context while, again, when you set 99% of the time you don't
David Herman wrote:
In general, I would like to see more updates and more convergence regarding the
modules specification, as many of us are now aiming at a (seemingly) wildly
moving target.
Well, the standard isn't out yet, so to some degree this is part of the
process. But I take the
Le 04/12/2012 20:25, Jason Orendorff a écrit :
On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens math...@qiwi.be
mailto:math...@qiwi.be wrote:
On 30 Nov 2012, at 22:50, Norbert Lindenberg
ecmascr...@norbertlindenberg.com
mailto:ecmascr...@norbertlindenberg.com wrote:
There's
Kevin Smith wrote:
1JS wants new syntax to be its own opt-in.
Right - except of course `let[i] = j;` isn't new syntax.
Of course, you cited only one sentence I wrote and cut the rest where I
adverted to the problem. But is it a real problem?
In non-strict, `let` is either an
for develoeprs I meant jQuery users too, being one of th emost popular API
out there.
What I meant with jQuery#add method is that last thing added is the one
returned, it does nto return the initial object, it returns the new result
out of a merge but this is not the initial this, this is a new
Of course, you cited only one sentence I wrote and cut the rest where I
adverted to the problem.
Sorry - I get creative with my cuts sometimes : )
But is it a real problem?
Probably not, but my POV is that if let is an identifier (and in non-strict
mode, it will be), then let it have all
On Dec 4, 2012, at 11:32 AM, Brendan Eich wrote:
In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also
13.2.2 [[Construct]], which layers on [[Call]], so [[Call]] is the lowest
layer single algorithm that has to deal with completions.
Pushing down into FunctionBody is
I would like to defend Dave against Kevin's wildly.
Yeah - it *was* a little inflammatory. Sorry, Dave. I think you rock, of
course : )
That the default loader knows about pathnames and .js is a good thing in
my view. You want something else, write another loader.
Actually, I feel like
it would be nice to add a #put(key, value) that returns value and see what
developers prefer on daily basis tasks :-)
anyway, if it won't change, it's OK, I had my answer, thanks
On Tue, Dec 4, 2012 at 12:03 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Dec 4, 2012 at 2:46 PM,
On Tue, Dec 4, 2012 at 3:07 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
it would be nice to add a #put(key, value) that returns value and see what
developers prefer on daily basis tasks :-)
anyway, if it won't change, it's OK, I had my answer, thanks
I like surveying actual
Allen Wirfs-Brock wrote:
On Dec 4, 2012, at 11:32 AM, Brendan Eich wrote:
In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also 13.2.2
[[Construct]], which layers on [[Call]], so [[Call]] is the lowest layer single
algorithm that has to deal with completions.
Pushing down
The survey I'd like to see is among underscore, jQuery, and other
popular libraries (go by NPM dependency frequency and client-side use
frequency), how do set-like methods work: return-this or return-v?
This is closer than a people-survey to mapping the cowpath.
/be
Herby Vojčík wrote:
recommend a more conservative approach for ES6: use the plain string
iterator as the protocol hook. Once the syntactic issues have been
I'd say not iterator. This is a special identifier, so to speak
instead-of-symbol-internal-name, so I would go for __iterator__.
Same
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path. Strict mode only has a bad reputation
because, in ES5, it is restrictive-only. There are
On Tue, Dec 4, 2012 at 1:04 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path. Strict mode only has
Brendan Eich wrote:
Herby Vojčík wrote:
recommend a more conservative approach for ES6: use the plain string
iterator as the protocol hook. Once the syntactic issues have been
I'd say not iterator. This is a special identifier, so to speak
instead-of-symbol-internal-name, so I would go for
Mark S. Miller wrote:
On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eichbren...@mozilla.org wrote:
Kevin Smith wrote:
I recommend allowing let declarations only in strict mode. This is the
simple, backwards-compatible path. Strict mode only has a bad reputation
because, in ES5, it is
I made a somewhat moreinterestling colored and (to me) more readable
version of the ES6 spec (previous one from last) using jorendorff's html
rendition as a foundation. Some may find this interesting, and some may be
blinded for life: http://benvie.github.com/es-spec-html/
On Tue, Dec 4,
agreed ... but then these analysis should be done before making decisions
in TC39 meeting notes.
If this was the case then, as I have said, I am OK with the decision ( de
gustibus )
br
On Tue, Dec 4, 2012 at 12:50 PM, Brendan Eich bren...@mozilla.org wrote:
The survey I'd like to see is
On Dec 4, 2012, at 11:43 , David Bruant wrote:
Le 04/12/2012 20:25, Jason Orendorff a écrit :
On Sat, Dec 1, 2012 at 2:09 AM, Mathias Bynens math...@qiwi.be wrote:
My guess would be that in 99% of all cases where `String.prototype.length`
is used the intention is to count the code points,
On Dec 4, 2012, at 1:54 PM, Brandon Benvie wrote:
I made a somewhat moreinterestling colored and (to me) more readable
version of the ES6 spec (previous one from last) using jorendorff's html
rendition as a foundation. Some may find this interesting, and some may be
blinded for life:
https://docs.google.com/spreadsheet/viewform?formkey=dGhXODJIWEFDVjA2RlNwSlF5amVVSVE6MQ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Dec 4, 2012, at 1:28 PM, Brendan Eich wrote:
Mark S. Miller wrote:
...
* It deoptimizes, e.g. a strict-mode function must be optimized to copy
actual parameter values into arguments if it could use the arguments object.
This one I just don't buy at all. In a strict function f,
On Tue, Dec 4, 2012 at 3:50 PM, Brendan Eich bren...@mozilla.org wrote:
The survey I'd like to see is among underscore, jQuery, and other popular
libraries (go by NPM dependency frequency and client-side use frequency),
how do set-like methods work: return-this or return-v?
underscore and
On Tue, Dec 4, 2012 at 2:18 PM, Mark S. Miller erig...@google.com wrote:
https://docs.google.com/spreadsheet/viewform?formkey=dGhXODJIWEFDVjA2RlNwSlF5amVVSVE6MQ
I have received private email complaining about the biased language in
this poll, and that as a result it is merely a push poll
Allen Wirfs-Brock wrote:
On Dec 4, 2012, at 1:28 PM, Brendan Eich wrote:
Mark S. Miller wrote:
* It deoptimizes, e.g. a strict-mode function must be optimized to copy
actual parameter values into arguments if it could use the arguments object.
This one I just don't buy at all. In a strict
Herby Vojčík wrote:
I am convinced it is doable (to have __legacy__ names but move to use
the better way once it is present) with the example of
__defineGetter__ Co.
I suggest those are bad precedents. They never were implemented in IE,
which led to ES5's meta-object APIs.
I confess I
On Tue, Dec 4, 2012 at 3:57 PM, Brendan Eich bren...@mozilla.org wrote:
Benchmarks won't cut it if there's no organic developer pressure.
That is not the behavior I've observed in response to benchmarks,
either among JS implementors, or in the industry as a whole. Developer
pressure and actual
On Mon, Dec 3, 2012 at 2:21 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
IMHO, a set(key, value) should return the value as it is when you address a
value
var o = m.get(k) || m.set(k, v); // o === v
// equivalent of
var o = m[k] || (m[k] = v); // o === v
If this pattern is
as discussed before, the problem with setDefault() approach you are
suggesting is that the dict(), at least in JS, will be created in any case.
var newDict = a.setDefault(k1, dict());
above operation will invoke dict() regardless k1 was present or less and
this is not good for anyone: RAM, CPU,
Could you specify more? If you mean SunSpider (2007) or V8/Octane, I
have some well-known bones to pick. These have sucked up a lot (not all)
of the oxygen available for the brain cells developers and casually
interested parties use to track JS performance, but due to a
who's-on-first effect,
On Dec 4, 2012, at 4:03 PM, Brendan Eich bren...@mozilla.org wrote:
We cannot have __legacy__ in ES6 and hope to get rid of it later IMHO.
We'll be committing to it as normative API for the indefinite future.
+1
You don't build web functionality with the intention of removing it. It just
I suppose it's worth noting I have an implementation of the ES6 standard
lib implemented using many ES6 features. Notably a significant amount of
@names. At least it's a useful example of them in actual use.
https://github.com/Benvie/continuum/tree/gh-pages/modules
On Tue, Dec 4, 2012 at 9:10
Brendan Eich wrote:
Hard to say what IE8's share will be, but IE9 did not implement strict
mode IIRC. IE10 did.
IE10 sort of did. The following code:
(function(){ 'use strict'; return !this; })();
returns false in IE10. Who knows what other
deviations from the standard there are...
--
Brendan Eich wrote:
Hard to say what IE8's share will be, but IE9 did not implement strict mode
IIRC. IE10 did.
Michał Z. Gołębiowski wrote:
IE10 sort of did. The following code:
(function(){ 'use strict'; return !this; })();
returns false in IE10. Who knows what other
deviations from the
65 matches
Mail list logo
