. Whether and
how we cut over was not decided, in my view.
Rushing to the new revolutionary calendar would be a mistake. We (TC39)
need to cash checks we've written, and not with our body :-P.
/be
Angus Croll wrote:
Name names. Who's idea was this? :)
On Thu, Jan 22, 2015 at 4:53 PM, Axel
Name names. Who's idea was this? :)
On Thu, Jan 22, 2015 at 4:53 PM, Axel Rauschmayer a...@rauschma.de wrote:
That would be my preferred solution: the name affects book covers,
domains, content, etc. = a significant amount of time and money.
Even worse than renaming ES6 now would be renaming
the alternative is that the second argument expects an array of 1 to n
source objects. This works with reduce and leaves way clear for future 3rd
argument (eg deep copy boolean)
On Tue, Dec 17, 2013 at 5:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
true ... as true is for
with the separate arguments solution the 'limit' argument is unusable
with the array solution you have a punctuation nightmare
the required regex seems easier in comparison
On Wed, Oct 16, 2013 at 5:54 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Splitting by one value or another
wiki-harmony docs that no
longer meet the standard would save a lot of wasted hours
thanks!
On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6 standard
The latest
I can confirm:
npm install harmony-reflect
node --harmony
require('harmony-reflect')
and I'm good to go with ES6 proxy syntax
thanks all!
@angustweets
On Fri, Oct 18, 2013 at 7:49 AM, Angus Croll anguscr...@gmail.com wrote:
Great info thanks (and Tom and Domenic)
A note on MDN
] on behalf of Angus
Croll [anguscr...@gmail.com
Also (to all) deleting or marking as obsolete all wiki-harmony docs
that no longer meet the standard would save a lot of wasted hours
@Angus, I'm sorry this happened, I try to keep up with marking wiki docs'
status as best as I can.
I know Rick
know if
there is still consensus on this.
In the prototype Firefox implementation, `new` is currently mandatory.
Regards,
Tom
2013/10/18 Angus Croll anguscr...@gmail.com
I couldn't find a commitment to a specific syntax in the latest ES6
standard
Gecko, chrome experimental, traceur
thanks André that works!
(I was going by
https://github.com/tvcutsem/harmony-reflect/blob/master/doc/traps.md which
says 'delete')
@angustweets
On Fri, Oct 18, 2013 at 9:38 AM, André Bargull andre.barg...@udo.eduwrote:
Follow up question for Tom et al...
Using
I couldn't find a commitment to a specific syntax in the latest ES6
standard
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n)
:42 AM, Claude Pache claude.pa...@gmail.comwrote:
I suggest:
[ ... mySet ]
or, if you don't want to use any new syntax:
Array.from(mySet)
—Claude
P.S. The syntax `[e for e of mySet]` is outdated in Harmony, you should
use `[(for let e of mySet) e]`.
Le 16 sept. 2013 à 17:33, Angus
I'm trying to figure out the most painless way, given a set, to return the
set's values as an array.
Possibilities:
1) harmony wiki (
http://wiki.ecmascript.org/doku.php?id=harmony:iteratorss=iterator)
suggests the following, but it is a syntax error in traceur, continuum and
node --harmony
let
Lending my support to Object.mixin accepting a function as the argument—but
no surprise there I guess :)
Note: since functional mixins and constructors are syntactically identical
we can now get gorgeously expressive—and make type inheritance way simpler
(for the first time allowing multiple type
, Angus Croll anguscr...@gmail.com wrote:
Lending my support to Object.mixin accepting a function as the
argument—but no surprise there I guess :)
Note: since functional mixins and constructors are syntactically
identical we can now get gorgeously expressive—and make type inheritance
way
No I more-or-less agree with your spiel.
I'm unclear why the group considered let/const is an issue for sloppy mode.
On Sun, Mar 10, 2013 at 9:57 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sun, Mar 10, 2013 at 7:50 PM, Angus Croll anguscr...@gmail.com wrote:
Thanks for this Rick
...@mozilla.org]
on behalf of Angus Croll [anguscr...@gmail.com]
*Sent:* Monday, March 11, 2013 17:08
*To:* Rick Waldron
*Cc:* TC39; es-discuss
*Subject:* Re: Jan 30 TC39 Meeting Notes
No I more-or-less agree with your spiel.
I'm unclear why the group considered let/const is an issue
1. Will proper tail calls only happen in strict mode, and if not are we ok
with losing backwards compatibility re. [function].caller and [
callingFunction].arguments?
2. Will tail call behavior apply regardless of the tail call syntax? (fn(),
fn.call, fn.apply)?
3. Will tail call behavior apply
Thanks Allen, those are the answers I wanted to hear :)
Seems like ES 6 proper tail calls will be a good for CPS too.
On Sat, Mar 9, 2013 at 5:22 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 9, 2013, at 3:00 PM, Angus Croll wrote:
1. Will proper tail calls only happen in strict
Yes the thread needs wrapping up. Maybe I can attempt summarize the dilemma
- with a question:
Is call/apply just a remedy for non-lexical this assignment? Or is it a
powerful feature in it own right.
I'm with the second camp, but I think I'm in the minority in this list
On Tue, Jun 5, 2012 at
, Angus Croll anguscr...@gmail.com wrote:
Not suggesting that arrow functions be special cased or that they ignore
|thisArg|. I'm suggesting for all relevant cases (=, bind and no
|this|) we
only throw an error on call/apply if the |thisArg| is non null.
That would not only be a breaking
On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich bren...@mozilla.com wrote:
You mean you still propose that (= 42).call({}) should throw, but
(function () { return 42; }).call({}) should not?
Sorry, this isn't a principled response. There should be no difference in
result between those two
On Jun 2, 2012, at 23:14, Brendan Eich bren...@mozilla.org wrote:
Angus Croll wrote:
To my mind (2) is the actual problem. To quote Yehuda the proposed
semantics interfere with more intentional uses of `call` and `apply`.
Users of call and apply who need to override |this| have
On Jun 2, 2012, at 23:14, Brendan Eich bren...@mozilla.org wrote:
So are you looking for an isBound predicate just to throw an error?
Sorry misread your question. Yes. For reasons stated.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
But that's exactly why we should be conservative about locking users into
hard bindings when their intentions are not clear (clear: 'bind' or no
|this| value, unclear: arrow functions). As someone who views call/apply as
cornerstones of the language and who's libraries depend on it, an
related: are explicitly bound functions going to get a 'target' reference
to the unbound function in ES6? I've manually set this property many times
(mainly for debugging)
On Thu, May 31, 2012 at 9:05 PM, Mark S. Miller erig...@google.com wrote:
On Thu, May 31, 2012 at 7:44 PM, David Herman
On Wed, May 30, 2012 at 2:01 PM, Rick Waldron waldron.r...@gmail.comwrote:
a means of detecting bound functions would essentially mitigate any
perceived pain points of fat-arrow-functions. If we can get consensus on
something like this, it would allay community concerns about the fat arrow.
You have some valid points Axel. Maybe the biggest problem is one of
communication - JSFixed has received a lot of attention and many followers
in just a few days - which suggests developers want more access to the
process by which the language is developed. To that end I hope we are
providing a
On Apr 28, 2012, at 22:24, Axel Rauschmayer a...@rauschma.de wrote:
The following two rules should be everything one has to know regarding
callable entities, in ES.next:
1. Method: `this` is an implicit parameter = use a method definition.
2. Non-method function: `this` is not an
On Apr 29, 2012, at 1:28, Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
I am not saying that the transition from the old rules to the new rules will
be entirely painless, but if the new rules are simple, that pain is worth
it, IMHO.
There are no new rules. Some
Then I guess we need another survey.
What does the JS arrow function proposal mean to you?
a) An abbreviated function syntax
b) A hard bound lexical |this| binding
c) Nothing
I'd gladly be proved wrong but my guess is most JS developers who don't
answer (c) will answer (a). (I see plenty of
I'm sorry that I could not reply to the multiple replies I got last
weekend. Simply can't get the time - plus I have a phobia of fan-out
replies (an issue with mail-based discussion groups?)
In any case here's a potted reply that addresses at least some of the
points:
1) Kevin et al suggested
4) Should it be a dynamic error to try to use apply/call to set the this
binding of an arrow function.
Cons
To much existing code speculatively binding the this value when invoking
a function.
I propose that call/apply simply ignore the this value when invoked on an
arrow function.
What is the
a function shouldn’t work radically (and silently!) different depending
on how it is invoked
every current JS function behaves exactly this way :-)
I'm painfully aware that I sound like a broken record on this, but
introducing a hard-bound function option while continuing to suport
dynamic-bound
I like dynamic this.
I favor hard-bound lexical |this| for standalone function calls only. Thats
where the problems are right now
The (this, ...) syntax seems unnecessarily gnarly - better to just default
to using base ref as |this| in a method call - since by now this is
expected behavior
On
On Fri, Mar 30, 2012 at 4:46 AM, Felix Böhm esdisc...@feedic.com wrote:
How about a loose-bound |this|, so that the function falls back to the
bound |this| instead of the global scope when no other options are
available (or `null` or `undefined` are passed to `.apply/.bind/.call`)?
I
On Apr 8, 2012, at 4:00, Herby Vojčík he...@mailbox.sk wrote:
No special cases for null or undefined, please.
Fine. Then we should just default to lexical binding for standalone function
calls - I'll stick my neck out and assert that it's the only area that needs
fixing with respect to
I don't see anything that is broken by arrow functions. You are
attempting to use arrows for defining methods which is incorrect.
Sorry, I obfuscated unnecessarily by making the inner functions into arrows
too.
But the important one is the withCircleUtilsFat function which is not a
method
Ha! nice catch :-)
My concern is with developers not knowing about the side effects of = and
therefore when to use it.
On Sun, Apr 8, 2012 at 4:09 PM, Kevin Smith khs4...@gmail.com wrote:
Which form has more brevity, then?
// This?
var withCircleUtilsFat = () = { ... };
// Or
Apologies if this is not yet nailed down. I'm looking for the following
details re. the arrow function grammar which I was unable to determine from
the strawman proposal:
1. Will the syntax support more than an expression in the function body?
The proposal appeared to be veering towards
I think its important to make a distinction between chained and unchained
prototypes...
By unchained prototypes I mean those that directly extend Object.prototype
(note that that every built-in prototype specified by ES5 is
unchained). Unchained prototypes are gorgeous - one instance defining
Sugar is fine for defining classes (as opposed to defining types in terms of
the constructor) but I get a little worried when I see the 'extends'
keyword. I'm probably biased but I see many JavaScript trainees eager to
simulate classical inheritance because it fits right in their comfort zone.
41 matches
Mail list logo
