Since every = Since ever
Sent from my Windows Phone
--
From: Andrea Giammarchi andrea.giammar...@gmail.com
Sent: 10/1/2013 7:35 PM
To: Tab Atkins Jr. jackalm...@gmail.com
Cc: es-discuss@mozilla.org
Subject: Re: what kind of problem is this fat arrow feature trying
Le 02/10/2013 04:35, Andrea Giammarchi a écrit :
setTimeout accept extra arguments ... I write JavaScript that uses
this feature.
`setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);`
What is evenAnObject? It doesn't look like a standard thing:
In current version, this works just fine:
var let = 6;
That could work with let being a contextual keyword.
But how about:
var a = 5;
let(a = 6)
{
alert(a)
}
Currently that does:
var a = 5;
a = 6;
let(6);
//purposeless block
{
Never mind, I just realized the let on MDN page is completely different
from ES6 let.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
There are two things here:
- In JS I (as well as most code in libraries I read) tend to use function
expressions a lot. The arrow notation is easier to read in my opinion. It's
shorter and more concise. That's a weak argument for it, but I think just
making the language more concise is an
As I understand it the problem with lookbehinds are not parentheses but
variable lengths. Therefore many regular expression flavors only allow
fixed-length lookbehinds[1], which could also be the restriction within
ECMAScript for now. This restriction could then be addressed at a later
point.
Sebastian,
Here is how I interpret Waldemar's post:
On Mon, Sep 30, 2013 at 5:55 PM, Waldemar Horwat walde...@google.com wrote:
No one has yet submitted a well-defined proposal for lookbehinds on the
table. Lookbehinds are difficult to translate into the language used by the
spec [...]
This
(In all fairness, Andrea was merely, and quite explicitly so, asking for
the rationale behind the fat arrow, not a scrutiny of his examples. Tab's
sarcastic response was unnecessary on a whole different level, too.)
On Wed, Oct 2, 2013 at 1:14 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com
Le 02/10/2013 10:37, Claude Pache a écrit :
+1. The big win of arrow-functions, is that it prevents from using various
ad-hoc kludges (`var that = this`, `[].some(..., this)`, etc), whose sole goal
is to defeat some unwanted feature (proper `this` binding in callbacks). Not a
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
first of all thank you all for your answers. In my experience I tend to not
write `var self = this;` or `var that = this;` since the introduction of
bind. Last Aymeric example is indeed part of what I was asking ...
developers like it because they don't have to write `.bind(context)` at the
end
On Tue, Oct 1, 2013 at 7:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
setTimeout accept extra arguments ... I write JavaScript that uses this
feature.
`setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);`
so fat arrow does not solve much here, I can use self as first
fat arrow does not add any capabilities but create the need to be sure
about the context.
In use strict fat arrow will bring a lovely `undefined` wich is undesired
so nothing is solved in there.
You need to be sure that the function/closure that is defining the fat
arrow is doing it in a `this`
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
One could say that JavaScript is an object oriented language where functions
are first class citizen. But JavaScript doesn't have methods, which in most oo
languages have the feature of always running with this being the object the
methods is executed on.
Was introducing a new type method
You need to be sure about the `this` because today you can `bind(anyObject
|| this)` while with fat arrow you can only bind `this` so you need to be
sure that the function context, the one everybody has always borrowed
through call and apply, is the one you expect to be.
In a new direction where
If you cannot use fat arrow to define prototypes than you cannot recycle
functions per each instance neither.
IIRC you are behind a pretty damn good framework that works on DOM and
indeed I was wondering if `handleEvent` would have been your choice there
too.
Thanks for your thoughts.
On Wed,
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?
Sebastian
On 2 October 2013
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,
Every time someone wants to make a framework in JS they need to consider
`this`. For example, a simple pubsu library could look like this:
publish(event, arg1, arg2)
subscribe(event, function(arg1, arg2){
//do something, e.g. this.something = arg1+arg2
}, this);
But now the callback has the
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.
On Wed, Oct 2, 2013 at 2:18 PM, Brendan Eich bren...@mozilla.com wrote:
Your reply
when do you need to address at runtime so many methods per instance/object ?
I've got the solve inline thing but I keep wondering when, where, and
why, we need so many inline runtime bound method attachments.
Any real code example beside showing how shorter it is ?
Promises could simply
Le 02/10/2013 19:45, Andrea Giammarchi a écrit :
so fat arrow does not solve much here, I can use self as first
argument and I am good.
`forEach` and all other arrays accept a second argument
`array.forEach(doStuff, boundContextObject);`
so fat arrow
Look at knockout.js and the way computed properties work. You quickly end
up with multiple bound functions on a single object, which are always
anonymous. The projects I've worked on lately has a lot of `var self =
this` to get things to work. Because we use knockout.js we don't have any
native
Andrea, it's difficult to understand why you think the fat arrow does
not help or I misunderstood your point, if |this| is already bound to
something, like for events, then you don't need it, if you want to bind
to something else then you use bind, if you want to bind to the outer
|this| then
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
in line
On Wed, Oct 2, 2013 at 2:54 PM, David Bruant bruan...@gmail.com wrote:
Le 02/10/2013 19:45, Andrea Giammarchi a écrit :
Yes, only for these particular examples.
Tab mentioned Array extras, that's the reason I've put them in the plate.
Promises ... never used them so far. I'll
It's a knockout choice I would say, nothing to do with the fact you cannot
have an `handleEvent` in there.
Look at [eddy.js](https://github.com/WebReflection/eddy#event-driven-js) or
put in in your project and you could handleEvent all the things, DOM and
not ^_^
As easy as that, but you
I honestly think that is a new model to explain out there, and for a
language many misunderstood already because of the magic `this` behavior
... fat arrow introduces a whole new world of foot-guns and a third option
over inheritance and/or mixins.
The fact you need a lot of bind in the DOM
Yes, I've missed this and if Kevin already studied real world use cases and
that's the result then it's OK.
What is misleading about this topic is that it looks like a shortcut for
common functions but it is absolutely not like that and this should be
emphasized quite a lot, IMO
We have
Just as a comparison point, in MontageJS we chose to implement the DOM Event
Target and Event Listener interfaces on Montage JavaScript objects to avoid
adding similar APIs under a different name.
Benoit
On Oct 2, 2013, at 19:18, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
It's
just because you mentioned it, I've implemented a 1:1 EventTarget ES3
compatible interface a while ago and the code is using a recycle 3
functions to rule them all* approach based on a simple Python style
without requiring bind, fat arrow, anything that fix the context in any
given method.
34 matches
Mail list logo
