I was recently discussion Promise optimizations (specifically, that in any
then chain at least one Promise object is created that goes unused), this
could be solved by some metadata that indicated whether the result of the
function would be consumed:
Promise.prototype.then = function(a, b) {
That is an interesting idea. In E's when-catch construct, which is the
direct ancestor of JS's .then, the when-catch construct is syntax whose
expansion to Kernel-E was dependent on whether the when-catch construct
statically occurs in a value consuming context. E is an expression
language, but in
On Mon, Mar 2, 2015 at 9:30 AM, John Lenz concavel...@gmail.com wrote:
I was recently discussion Promise optimizations (specifically, that in any
then chain at least one Promise object is created that goes unused), this
could be solved by some metadata that indicated whether the result of the
On Mon, Mar 2, 2015 at 10:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 2, 2015, at 9:30 AM, John Lenz wrote:
I was recently discussion Promise optimizations (specifically, that in
any then chain at least one Promise object is created that goes unused),
this could be solved
I think the fact you had to write two solutions where one attach to the
object the listener and another one needs a double arrow (rainbow) already
shows we have a hole in the language once covered by arguments.callee.
just to make sure we are not misunderstanding each other: I wrote
two
Just to be clear, I agree with you that we should not rush to add
special forms where combinators may suffice. However:
Claus Reinke wrote:
We just got rid of the 'this' workarounds, and it cost us a whole
second set of function expressions.
We would have had this problem anyway. When I did
On Feb 27, 2015, at 12:27 AM, Leon Arnott wrote:
I feel a little unhappy that one meta-property, `new.target`, is lexically
scoped in arrow functions but these new ones aren't, without much obviously
distinguishing them. I guess you could concoct the reasoning that since
arrows can't be
On Feb 27, 2015, at 7:59 AM, Claus Reinke wrote:
For concise methods, the problem is already solved by 'this',
isn't it?
({f(n){return n1?n*this.f(n-1):1}}.f)(6)
720
No, not for the general case. You could have arrived here via a 'super' method
call in which case 'this.f' will take
nope, you are limiting your object to have only one listener per event, I
think that's not quite how reality is. You gonna lose that listeners next
time somebody use same name with the same object.
In (?:io|node)js you have EventEmitter that exposes .on, on web even jQuery
needs that reference in
For concise methods, the problem is already solved by 'this',
isn't it?
({f(n){return n1?n*this.f(n-1):1}}.f)(6)
720
No, not for the general case. You could have arrived here via a 'super' method call in which case
'this.f' will take you back to a subclass' f rather then recurring on
and yet you haven't removed any anonymous arrow listener. Assign first?
Mostly nobody will do that, it's just less natural then `obj.on(something,
()=happening)`
personally? Yes, I tend to assign listeners somewhere, at least when I
intend to remove them later. I've even been known to assign
Can you show an example of how callee is used with a fat arrow function?
((n)=n1? n*function.callee(n-1) : 1)
meta-level tools are powerful, which makes them ever so tempting.
They are too powerful to be used for tasks for which current
language-level tools are sufficient. Using a
nope, you are limiting your object to have only one listener per event, I
think that's not quite how reality is. You gonna lose that listeners next
time somebody use same name with the same object.
true. For cases where that isn't enough, i assume you're thinking of
canceling from within the
I think the fact you had to write two solutions where one attach to the
object the listener and another one needs a double arrow (rainbow) already
shows we have a hole in the language once covered by arguments.callee.
The more you write examples, the more you convince me we are missing callee
;-)
I feel a little unhappy that one meta-property, `new.target`, is lexically
scoped in arrow functions but these new ones aren't, without much obviously
distinguishing them. I guess you could concoct the reasoning that since
arrows can't be `new`'d, `new.[meta-property]` is meaningless in it - but
another basic example with listeners
```
window.addEventListener('load', (e) = {
// how am I going to remove this listener?
console.log('everything loaded');
});
```
Specially on UI world, many libraries do attach tons of things at runtime,
within methods, and have no way to remove them if
Am I the only one who finds it weird to use `function.something` inside a
function?
```
function doSomething () {
function.self...
}
```
That's why I was thinking in something more related to the scope than to
the function object itself.
On Thu, Feb 26, 2015 at 11:32 PM, Matthew Robb
Here is a new proposal for some additional meta properties that should be
considered for ES7
https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md
I've added this to the agenda for next months TC39 meeting but pre-meeting
discussion is always welcomed right here.
Allen
agreed ... between `self` and `callee` probably `self` is better. Anyone
with a different/new idea?
On Thu, Feb 26, 2015 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache claude.pa...@gmail.com
wrote:
Alternative name for `function.callee`:
I personally wouldn't mind `self` but it has been historically used as
context or global reference, while callee ... you don't probably need to
explain what's that about.
On the other hand, from `arguments` object, `callee`was more semantic but
it feels not th ebest choice from `function` indeed.
I think it's easier to convey the message to never use callee instead use
function.self.
On Feb 27, 2015 1:52 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
((n)=n1? n*function.callee(n-1) : 1)
On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote:
Can you show an example of how callee
function.current?
From: Andrea Giammarchimailto:andrea.giammar...@gmail.com
Sent: 2015-02-26 18:56
To: Tab Atkins Jr.mailto:jackalm...@gmail.com
Cc: es-discussmailto:es-discuss@mozilla.org
Subject: Re: Proposal: Additional Meta Properties for ES7
agreed
: Re: Proposal: Additional Meta Properties for ES7
agreed ... between `self` and `callee` probably `self` is better. Anyone with
a different/new idea?
On Thu, Feb 26, 2015 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache claude.pa
Alternative name for `function.callee`: I find that `function.self` sounds
better in case of recursive call (and probably in other cases as well).
—Claude
Le 26 févr. 2015 à 23:47, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
Here is a new proposal for some additional meta properties
Jr. jackalm...@gmail.com
Cc: es-discuss es-discuss@mozilla.org
Subject: Re: Proposal: Additional Meta Properties for ES7
agreed ... between `self` and `callee` probably `self` is better. Anyone
with a different/new idea?
On Thu, Feb 26, 2015 at 11:50 PM, Tab Atkins Jr. jackalm...@gmail.com
Can you show an example of how callee is used with a fat arrow function?
(()={alert(callee);})()
Thanks.
On 2/26/15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Here is a new proposal for some additional meta properties that should be
considered for ES7
On Thu, Feb 26, 2015 at 3:27 PM, Claude Pache claude.pa...@gmail.com wrote:
Alternative name for `function.callee`: I find that `function.self` sounds
better in case of recursive call (and probably in other cases as well).
Agreed that callee, while technically accurate, is a clumsy word and
((n)=n1? n*function.callee(n-1) : 1)
On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote:
Can you show an example of how callee is used with a fat arrow function?
(()={alert(callee);})()
Thanks.
On 2/26/15, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Here is a new proposal for
I am positive that there will be good reasons I am just curious what they
might be, why not: `function(){ function(); }`
- Matthew Robb
On Thu, Feb 26, 2015 at 8:00 PM, Tom Schuster t...@schuster.me wrote:
I think it's easier to convey the message to never use callee instead
use
Or the following three forms would be great:
// normal form
function();
// or
function.invoke();
// additionally
function.call();
function.apply();
- Matthew Robb
On Thu, Feb 26, 2015 at 9:29 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I am positive that there will be good reasons I am
30 matches
Mail list logo