On Nov 10, 2013, at 9:32 PM, Oliver Hunt oli...@apple.com wrote:
I still cannot recall what the usage scenario that required undefined = not
provided was, but this seems like a very good argument for that decision
being wrong.
C'mon, we have been over this a kajillion times. Delegation
Dmitry Soshnikov wrote:
Moreover, for this particular `splice` example, I don't think the `(start,
deleteCount, ...rest)` is the best signature (not to say, incorrect signature).
As again was mentioned, a var-args function seems should just use the `...rest`
params, and exactly starting from
David Bruant wrote:
Also note that there is likely to be actual computational overhead in
both creating a rest argument and in destructuring it. In some
cases, that overhead may be an issue.
Can implementations optimize this pattern to remove this overhead?
Surely they can. Will they? If it
Andrea Giammarchi wrote:
I think ignoring undefined, if that's what has been decided, is a
mistake. As easy as that.
Read this thread, or past threads:
https://mail.mozilla.org/pipermail/es-discuss/2013-September/033406.html
which links to
Mark Miller wrote:
http://en.wikipedia.org/wiki/Confirmation_bias
*Confirmation bias* (also called *confirmatory bias* or *myside bias*)
is a tendency of people to favor information that confirms their
beliefs or hypotheses http://en.wikipedia.org/wiki/Hypothesis.^[Note
1]
David Bruant wrote:
Le 10/11/2013 23:34, Brendan Eich a écrit :
Dmitry Soshnikov wrote:
Moreover, for this particular `splice` example, I don't think the
`(start, deleteCount, ...rest)` is the best signature (not to say,
incorrect signature). As again was mentioned, a var-args function
seems
Andrea Giammarchi wrote:
You replied as if I took part in those conversations and forgot ...
that might be the case but AFAIK (indeed) is not.
You are on the list, this came up less than two months ago. Google site
search works, please use it. site:mail.mozilla.org es-discuss undefined
Allen Wirfs-Brock wrote:
Can someone remind me what we decided about 'arguments' and arrow
functions. I pretty sure we discussed this recently and reach some
conclusion but I can't find it in either meeting notes or es-discuss.
And I don't trust the correctness of what the spec. draft
Domenic Denicola wrote:
As of 6 months ago there was a shift toward treating it the same as `super`,
i.e. use the enclosing scope's. I feel like this was agreed on more recently
too. But I am not sure.
http://esdiscuss.org/topic/introduction-comprehensions-beyond-arrays#content-1
From
Python has requirements for over-parenthesization which we were trying
to avoid. Nevertheless, did you consider
5. Except on right of assignment and in actual argument position, yield
expressions must be parenthesized
This is easy to do grammatically if we change the over-general
Brendan Eich wrote:
I say over-general because: do we really want this to be valid ES6?
class D extends B = C {
}
Using a higher-precedence expression non-terminal seems better. How
about the next lower-precedence
Sorry, higher-precedence (jetlag)
nonterminal that does not end
Allen Wirfs-Brock wrote:
Not to pick a fight (yet), but that's a bit strong. Recall I'm proposing
value objects with operators dispatching 2-ary functions based on arguments, in a
way that is inline-cacheable. Still working on it (Christian Hansen helping),
update anon.
Sure, but that is
Mark S. Miller wrote:
Another way to go is far higher precedence, say
LeftHandSideExpression? That avoids all arithmetic operators,
unary and binary.
If we go with the highest plausible precedence, we can always lower it
later. Not vice versa.
Yep -- I'm warming up to
Domenic Denicola wrote:
I believe the argument is that you'd want `await a + b` to be `(await a) + b`,
whereas with `yield` it's `yield (a + b)`.
We need a debugged grammar for await, when ready. We have one for yield
(existence proofs in several browsers now), and I think we can fix
Mark S. Miller wrote:
So would LeftHandSideExpression satisfy both needs?
Mark, LeftHandSideExpression is my proposal for the replacement of
AssignmentExpression in ClassHeritage, *not* for anything to do with
YieldExpression.
I note that this also raises the issue of the precedence of the
Brendan Eich wrote:
C# 5.0
(http://www.microsoft.com/en-us/download/dlx/thankyou.aspx?id=7029)
makes await expression both a statement-expression (the entirety up to
the ; terminator of a statement-expresion)
s/statement-expresion/expression-statement/ on last line, blargh
There's no particular reason not to do something like that, except:
1. It is not usable (see
http://www.jroller.com/cpurdy/entry/the_seven_habits_of_highly1%23comment-1130764636000).
2. Math is becoming a dumping ground, as noted up-thread.
3. Polyfillability is not important if old code can
Anne van Kesteren wrote:
OnTue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Spread now requires an Iterable rather than an array-like
This is different from how sequenceT behaves in IDL. (It uses array-likes.)
:/
This is more general, since array-likes
Anne van Kesteren wrote:
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eichbren...@mozilla.com wrote:
Anne van Kesteren wrote:
This is different from how sequenceT behaves in IDL. (It uses
array-likes.) :/
This is more general, since array-likes should be iterable to be like
arrays,
Tristan Zajonc wrote:
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
Is this bug related to operator overloading? It seems just the nature
of the beast with mutable reference types. Pretty much all JS matrix
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with declarative syntax to
solve several problems:
1. Backward compatibility,
Tristan Zajonc wrote:
Sorry, at most I'm only proposing every *existing* operator prefixed
by ., not new operators. So things like
.+, ./, .*, .-., .%, .==, .!=, ., ., etc. These would be called dot
operators. This is all that's required by the
technical computing use case.
Why is the dot
Tristan Zajonc wrote:
One clarification on the value objects proposal... The JSConf slides
say that immutability is implemented as an implicit
Object.freeze(this) on return in the constructor. Is this meant as
shorthand for a deep freeze?
Yes, although depth may be hard to generalize. A
Dean Landolt wrote:
The PEP Tristan posted offers a pretty compelling case for
distinguishing elementwise operators from objectwise ones (although
not for this dot syntax per se, they went with a ~-prefix):
http://www.python.org/dev/peps/pep-0225/
Got it, thanks. We could indeed do .+, .*,
André Bargull mailto:andre.barg...@udo.edu
October 29, 2013 11:46 AM
No. ;-)
What's wrong with me? Have I become a Rubyist, LOL?
Thanks, clearly under-caffeinated today.
/be
js 1.*2
2
- André
Brendan Eich mailto:bren...@mozilla.com
October 29, 2013 11:39 AM
Got it, thanks. We could
André Bargull wrote:
There are the usual ASI problems. For example this is currently valid:
```
a
~+ b
```
It is parsed as:
```
a;
~+ b;
```
The fix we entertained for 'is' and 'isnt' was restricted productions:
AdditiveExpression [no LineTerminator here] '~+' MultiplicativeExpression
Tristan Zajonc wrote:
What about +:? This actually has some visual appeal if primary
motivation is elementwise operations and is a syntax error with that
ASI example. The downside is that it can end up pretty close to
existing syntax like {a+:1} vs. {a:+1}, although I don't expect that
to
Axel Rauschmayer wrote:
I would love to have a way to write function calls infix. That may
cover your use case as well. That is (strawman syntax):
arg1 #func arg2
would be syntactic sugar for
func(arg1, arg2)
Advantages: more versatile, less grawlixy.
# is pure grawlix. It's also
Brendan Eich wrote:
Tristan Zajonc wrote:
What about +:? This actually has some visual appeal if primary
motivation is elementwise operations and is a syntax error with that
ASI example. The downside is that it can end up pretty close to
existing syntax like {a+:1} vs. {a:+1}, although I
Tristan Zajonc mailto:tris...@senseplatform.com
October 27, 2013 5:47 PM
I apologize for jumping in here with an incomplete understanding
what's being proposed, but perhaps somebody can help clarify it for
me. I've been following value types and operator overloading
discussion with great
Brendan Eich wrote:
The API Function.defineOperator(symbol, type1, type2) would be
perfect to support this. However I assume this is not the intention?
Is there any openness to supporting user defined infix operators or
at least an extended set similar to Python's PEP 225 proposal
(http
Tristan Zajonc wrote:
Having === be reference equality is fine if that's a hard JS
requirement. For a matrix API, there is some flexibility on
comparison operators, but transient value comparison returning a
single boolean is the most natural, other issues aside. I'm not sure I
fully
the direction and has no issues, then
it's perfect. I just realized that Brendan Eich created JS so I assume
he fully knows about any compatability issues. His solution is cleaner
for conversions.
Thanks :-). You're right that extant code on the Web might use float32
as a function name, but that's ok
Brendan Eich wrote:
Here's what Alon wrote recently:
Alon Zakai, creator of Emscripten, first among discoverers of asm.js.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Yup.
Look (Licio), we've been over this many times, recorded here in
es-discuss (directly in posts and in TC39 meeting notes). We are not
adding generator syntax lightly. It is necessary to preserve backward
compatibility.
/be
Till Schneidereit mailto:t...@tillschneidereit.net
October 26,
Which were inspired by the classbox work that built on Smalltalk classes.
/be
On Oct 21, 2013, at 8:29 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
When we proposed scoped object extensions we looked at Ruby's refinements.
On Mon, Oct 21, 2013 at 11:25 AM, Tab Atkins Jr.
@@tagForToString? Er, no.
It's actually not the whole return value of any toString call, of
course. It is the %s in [object %s] returned by
Object.prototype.toString.call(x) for an object x. This suggests
@@objectToStringTag
or something along those lines. Does that help?
/be
Nathan Wall
Allen Wirfs-Brock wrote:
The use case that we don't support well is any sort of back wards iteration of
the characters of a string. We don't current have an iterator specified to do
it, nor do we have a one stop way to test whether we at looking at the trailing
surrogate of a surrogate pair.
Yes, this is intentional and goes all the way back to ES4's original
destructuring proposal, based on array-pattern destructuring implemented
in Opera's Futhark engine. See
http://wiki.ecmascript.org/doku.php?id=discussion:destructuring_assignment#contrast_to_normal_assignment
We want
It's hard to add extra optional arguments to a long-standing built-in.
People write code that passes an extra arg that has been ignored till
the change; browsers that try shipping the new version then break that
content, user blames browser (rightly so) but also the page, sometimes
(not
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15, 2013 12:45 AM
Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote:
We already have good motivation for :: anyway, as sugar for bind.
This gives relief to the OO side of the expression problem trade-off
by allowing
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
October 14, 2013 6:09 PM
Speaking from the perspective of someone whose probably has permanent
OO brain damage, it doesn't do a lot for me.
The reason I invoke a method on an object is because I want to do
polymorphic dispatch on the method
Russell Leggett wrote:
The big issue I see here is chaining.
`_.reduce(_.map(_.filter([1,2,3,4,5],x=x%2 ===
0),x=2*x),(x,y)=x+y)`
Is a lot less readable than
`[1,2,3,4,5].filter(x=x%2===0).map(x=2*x).reduce((x,y)=x+y))`
P.S. This
Benjamin (Inglor) Gruenbaum wrote:
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here (why would it not invoke the setter?)
Allen confirmed, but just to be clear,
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15, 2013 2:00 PM
I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_
means `b(a,x_1,...,x_n)`
No, rather: `b.call(a, x_1, ..., x_n)` but with the original
Function.prototype.call (not any shadowing b.call).
I think
Anne van Kesteren mailto:ann...@annevk.nl
October 14, 2013 6:16 AM
The idea is to use a somewhat more unique separator, e.g. $sub/. Old
browsers would simply fetch the URL from the server and if the server
is written with legacy in mind would serve up the file from there. New
browsers would
Andreas Rossberg wrote:
My take-away was that scoped extension methods are only bearable in a
language with a static, nominal class system (like C#), where the
additional lookup dimension can be resolved at compile time.
Right.
The http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf
Till Schneidereit mailto:t...@tillschneidereit.net
October 13, 2013 2:39 PM
On Sun, Oct 13, 2013 at 8:40 PM, Brendan Eichbren...@mozilla.com wrote:
Till Schneidereitmailto:t...@tillschneidereit.net
October 13, 2013 11:28 AM
And now it causes problem for TC39, browser vendors, sites that use it
that are still
referenced by methods.
I believe that classboxes depends upon this reprocessing step to
maintain its invariants.
My point!
/be
Allen
Brendan Eich mailto:bren...@mozilla.com
October 14, 2013 8:42 AM
Right.
The http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf work,
which
John Lenz mailto:concavel...@gmail.com
October 14, 2013 9:59 AM
Does this performance hit still exist in light of Symbol?
Yes. Symbol is just an alternative property name type. Think of it in
pseudo-ML:
type PropertyName = String | Symbol
where of course practical engines optimize
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
October 14, 2013 11:19 AM
You can dynamically change the superclass of a class but that will
trigger the recompilation process for that class and its subclasses
(implies that superclass to subclass links must be available). This is
mostly about
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 14, 2013 12:37 PM
On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
So, see the
http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf work, which
inspired Ruby refinements as well
Russell Leggett mailto:russell.legg...@gmail.com
October 14, 2013 12:51 PM
I get that this isn't really the same, but I think one really viable
solution for the scoped method problem (which is really just the
expression problem, right?)
The expression problem
To search es-discuss, I use site:mail.mozilla.org es-discuss as first
two terms in a Google search. Sometimes I just use es-discuss. If you
add __proto__ you'll find lots to read. Add meeting notes and you'll
find recorded TC39 decisions.
I usually find links and include them here to avoid
Andrea Giammarchi wrote:
__Current Status__
(Thanks for the dunders! :-P)
Instead of formalizing its form, ES6 accepted `Object.setPrototypeOf`
as described in specs and decided to silently move beside, but still
have in specs, the dunder `__proto__` form, fixing at least a couple
of
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
October 14, 2013 1:32 PM
I meant that IIRC `obj[__proto__]` should not invoke that Annex B
specified getter (@Benjamin, Annex B is where you'll find everything
related indeed) but `obj.__proto__` will ... unless once again I've
missed some
Russell Leggett mailto:russell.legg...@gmail.com
October 14, 2013 2:07 PM
On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Russell Leggett mailto:russell.legg...@gmail.com
mailto:russell.legg...@gmail.com
October 14
Rick Waldron wrote:
Do you mean more then inclusion in Annex B?
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-other-additional-features
http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-other-additional-features
The committee and community made the right move to go with
Erik Arvidsson wrote:
I'm concerned about the latest version of this on the wiki. The
edition parameter requires that we ship 2 tablestoday. This seems
like it might change to 3 in ES7 and n in ES(n+4). I think the only
reasonable requirement is that it matches what the engine actually
uses.
Jorge Chamorro wrote:
The only work around for that is making as few requests as possible.
+∞, +§, and beyond.
This is deeply true, and a hot topic with browser/network-stack
engineers right now.
/be
___
es-discuss mailing list
, neither a
getter once deserialized.
Is this correct? Yeah, I remember that different accessors looked
weird to me too ... thanks for clarification.
Best Regards
Brendan Eich mailto:bren...@mozilla.com
October 14, 2013 1:43 PM
What you just wrote is not true of __proto__ in SpiderMonkey
Apologies for the (iPad + haste)-induced typos below :-(.
/be
Brendan Eich mailto:bren...@mozilla.com
October 13, 2013 10:17 AM
Benjamin (Inglor) Gruenbaum wrote:
However, this is considered bad practice for many reasons I don't
have to repeat here (what if other libraries also override
.
/be
-- Forwarded message --
From: Erik Arvidsson erik.arvids...@gmail.com
mailto:erik.arvids...@gmail.com
To: Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com
Cc: es-discuss es-discuss@mozilla.org mailto:es-discuss@mozilla.org
Date: Sun, 13 Oct 2013 13:32:23 -0400
Subject
Erik Arvidsson wrote:
Let's not kid ourselves. WeakMaps have bad user ergonomics and runtime
ergonomics. I think at this point non method functions are much better.
Hang on, relationships and new syntax can solve both performance and
ergonomics concerns, we think.
Perhaps you missed the
Anne van Kesteren mailto:ann...@annevk.nl
October 11, 2013 12:34 AM
On Fri, Oct 11, 2013 at 3:53 AM, Brendan Eichbren...@mozilla.com wrote:
On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchi
andrea.giammar...@gmail.commailto:andrea.giammar...@gmail.com wrote:
You are confining the
Jorge Chamorro wrote:
On 11/10/2013, at 03:53, Brendan Eich wrote:
On Thu, Oct 10, 2013 at 8:10 PM, Andrea Giammarchiandrea.giammar...@gmail.com
mailto:andrea.giammar...@gmail.com wrote:
You are confining the problem in HTTP only scenarios while the
solution provided
Erik Arvidsson wrote:
... My point is that it seems not everyone heard Mark's statement
that weakmaps should not be used to implement relationships except in
preprocessors targeting ES6 (assuming we get relationships into ES7).
Exactly.
Ok, that's what I was hoping for. We need Traceur,
Andrea Giammarchi wrote:
Agreed that this might be the wrong place but also it's surprising
that there was a W3C recommendation and Mozilla, the most standards
promoter I know, ignored it.
Yes, we went with JSON over XML. Sorry.
/be
___
es-discuss
I agree with your approach that values ease of content-only (in the
HTML, via script src= ref=) migration. I think David and others pointing
to HTTP 2 undervalue that.
However, Russell's counter-argument that fallback in older browsers to
loading lots of little files, request by request, from
Jeremy Darling wrote:
I understand g(un)zip is the de-facto standard, I would just hate to
see such a small detail overlooked at the end of the day when a one
liner pretty much covers it.
Oh, and I'll 2nd the way nicer than any AMD solution. This also
keeps readability in mind along with
Andrew Fedoniouk wrote:
http://wiki.ecmascript.org/doku.php?id=discussion:date_literal_syntax
http://wiki.ecmascript.org/doku.php?id=proposals:date_literal_syntax
https://encrypted.google.com/#q=site:https%3A%2F%2Fmail.mozilla.org%2Fpipermail%2Fes-discuss%2F+%22date+literal%22
Thanks
Andrew Fedoniouk wrote:
Iftomorrow JSON2 will appear it will come up with its own date
literals.
This is what people are telling you on this thread won't happen. Of
course, it could happen -- but given all the things we worry about,
this one is way, wa down on the list.
/be
I could go with internal slot. Is data necessary?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Nathan Wall mailto:nathan.w...@live.com
October 7, 2013 8:05 PM
This should be a quick answer; I'm just looking for clarity. Are
there any situations where internal data properties may be inherited?
For example:
Set foo to bar.[[Baz]]
Does `foo` ever result in a non-undefined value if
Yusuke SUZUKI wrote:
Make sense. So microtasks won't be introduced yet, but Promises and
asynchronous execution semantics (enough for Promises) are introduced
into ES6. Is it correct?
And enough for modules.
And really, as dherman points out, the event loop and shared state
concurrency have
I think this is right, we need help and are open to it from someone who
can lift the weight. Waldemar may be able to help, I'm not sure how much
(but he wrote the ES3 regexp spec, so at least as reviewer he is a key
part of the solution).
Sebastian, if you have time to help, that would be
It would be easier if we had the other let-specific special forms,
wouldn't it?
ES6 draft makes let a reserved identifier. This is not backward
compatible, but we're trying to find out what we can get away with. The
fallback if we can't reserve is to do what we will do with 'yield (not
yet
Andrea Giammarchi wrote:
fat arrow does not add any capabilities but create the need to be sure
about the context.
This does not make sense. The problem of being unsure about which this
already exists. Adding arrows does not make it worse. The new syntax
makes it better, compared to 'var
Sebastian Zartner wrote:
I can try to help, though my time and technical knowledge about regexp
implementations are limited. So wouldn't someone of the people, who
already implemented a working regexp engine, be a better help? Did
somebody of you ever contact the e.g. the people behind PCRE?
Your reply incoherently flattens some of my words with leading ' '
citation prefixes. But I'll be brief here, no need to reply:
Andrea Giammarchi wrote:
In CoffeeScript the fat arrow behaves differently having a dynamic
this, am I correct?
No, you are incorrect. CoffeeScript's = binds this,
Andrea Giammarchi mailto:andrea.giammar...@gmail.com
October 2, 2013 2:25 PM
Thanks. And do we know which one is the most common case or any
reason we won't have the same in ES6 ? I see both options as a win.
Having only the = version looks like a huge limit in arrow potential.
We went
3
/be
Jason Orendorff mailto:jason.orendo...@gmail.com
October 1, 2013 8:04 AM
Links to sections have changed.
Old:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-12.7.3.1
New:
Allen Wirfs-Brock wrote:
Currently, that works for everything but null
and undefined, so I assume that this pattern is used quite a bit.
Do you think it really is?
I don't. (That is, I don't see much x.toString() feeding into bracketed
property lookup, if any.)
Explicit .toString()
No, we are using undefined actual parameter value, not argument.length,
to trigger defaulting -- as discussed many times and cited by me (again)
recently in reply to Oliver. Please do not go backward.
/be
___
es-discuss mailing list
Andrea Giammarchi wrote:
Does `null` count as undefined too
No. See the draft spec and many threads and meeting notes.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thread-hijacking is poor form.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Anne van Kesteren mailto:ann...@annevk.nl
September 30, 2013 6:27 AM
Right, which is why symbols are so nice as HTMLCollection gets around.
Yes, for naming meta-level stuff.
For naming methods, not nice. This limits future additions.
/be
Kevin Smith mailto:zenpars...@gmail.com
September
Boris Zbarsky wrote:
Note that the set of properties iterated by for/in on HTMLCollection
is ... sigh. But I don't think that should constrain what for/of
does, hopefully?
Not constrained at all, by design.
The new for-of forms trigger the iteration protocol. for-in is what it
is (and
You shoot, you score.
This is decisive -- cc'ing Allen.
/be
Brandon Benvie mailto:bben...@mozilla.com
September 30, 2013 9:52 AM
Calling Object as a function is currently infallible and I've seen
plenty of code that makes this assumption. This should probably not be
changed.
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 30, 2013 2:57 PM
Symbol.prototype.toString uses in in the current draft (see
http://esdiscuss.org/topic/a-new-es6-draft-is-available#content-4).
I suppose there is no reason not to make it directly accessible. What
should be the named
Brandon Benvie mailto:bben...@mozilla.com
September 30, 2013 8:48 PM
I'm actually now really curious what the following does:
```
function foo(x, y = (() = { arguments[0] = foo; return bar })()) {
return [x, y];
}
Easy: arguments is an early error in the body of an arrow.
Kevin Smith mailto:zenpars...@gmail.com
September 27, 2013 9:44 PM
All the noise we made about Object.extend was unclear? From jQuery:
https://github.com/jquery/jquery/blob/master/src/core.js#L157
Many similar functions, going back to Prototype's Object.extend:
Object.extend
Kevin Smith mailto:zenpars...@gmail.com
September 27, 2013 9:56 PM
div id=@iterator/div
scriptalert(document.getElementsByTagName(div)[@iterator])/script
This is a good point, and one which I was trying to reason about (way)
upthread. This might do it - have to sleep on it, though...
Axel Rauschmayer mailto:a...@rauschma.de
September 28, 2013 2:49 PM
Has this feature ever been considered?
Lots of times, going back at least as far as
http://wiki.ecmascript.org/doku.php?id=discussion:resurrected_eval
Read under Resolved issues.
SpiderMonkey had a two-argument eval for
David Herman wrote:
We've seen this movie before: arrays are just objects, integers are just
doubles, environment records are just objects...
Some of my biggest regrets! Top five list material (don't list the other
two, please).
/be
___
Kevin Smith wrote:
Whether you personally use it, for-in is a reality. Introspection
of objects happens, so if you ship a library that's putting
meta-level properties into objects it needs to make them
non-enumerable to be robust in the face of client code that uses
for-in
Tom Van Cutsem wrote:
var f = function(x,y) (z) {
Tiny bike-shed-ish comment that we need a linking punctuator so that
arrow function syntax can be extended likewise:
var f = function (x, y) : (z) {...}
Arrow form showing expression body:
var f = (x, y) : (z) = x*y/z;
An alternative
Maybe, but:
(1) annotations are user-hostile even in a language like Rust, wherefore
type-and-lifetime inference, which you are not proposing.
(2) we need a sane default, if not inference.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Waldemar Horwat mailto:walde...@google.com
September 27, 2013 3:45 PM
It's even back in ES6 with then. I find it truly weird that we're
trying to use two different mechanisms to get the then and iterate
metaproperties. We should be cutting down the complexity, not adding
to it in a manner
Anne van Kesteren mailto:ann...@annevk.nl
September 26, 2013 5:41 AM
What Tab meant is that within the platform only CR and CRLF are
normalized to LF and no other code points. This is true for HTML as
well.
This thread is to sort out the LINE and PARA seps. No one likes 'em.
JSON missed them.
801 - 900 of 4618 matches
Mail list logo
