How Function.getArguments()?
Function.getArguments() should return the arguments array.
let args = Function.getArguments();
if(args.length != 2) throw new Error(invalid arguments);
--
View this message in context:
Allen Wirfs-Brock wrote:
Also, I would outlaw (new) overloads like
Document:
TouchList createTouchList(Touch... touches);
TouchList createTouchList(sequenceTouch touches);
Yeah, why are *new* (this is from Web Events, not legacy) APIs doing the
crazy. Answer: because people imitate
On 11/12/13 11:24 AM, Brendan Eich wrote:
Yeah, why are *new* (this is from Web Events, not legacy) APIs doing the
crazy. Answer: because people imitate older crazy APIs, and WebIDL
supports this.
No. In this case it's because the spec started out one way (with the
sequence, iirc) but then
On 11/12/13 12:21 PM, Brendan Eich wrote:
Oh, ok -- new-ish legacy. This makes the case for stronger normative
specs against such overloading, starting with WebIDL.
Again, WebIDL disallowing this would not have helped; the real issue was
a semantic problem.
I'm all for simplifying the
Boris Zbarsky wrote:
Oh, ok -- new-ish legacy. This makes the case for stronger normative
specs against such overloading, starting with WebIDL.
Again, WebIDL disallowing this would not have helped; the real issue
was a semantic problem.
What semantic problem required two createTouchList
On 11/12/13 7:19 PM, Brendan Eich wrote:
What semantic problem required two createTouchList functions having
the same name?
The fact that some UAs shipped one version of it others shipped another
(as the spec evolved), then the working group decided to spec one of
those versions but there
On 11/11/13 1:22 AM, Jonas Sicking wrote:
I think the number is very low. I think I've heard of a total of four
DOM functions which currently treat not passed as different from
explicitly passed undefined. And we're working on changing those so
that the two are treated the same. Unclear if we'll
That is excellent! Has all the upsides of the best of the other proposals
and none of the downsides.
On Sun, Nov 10, 2013 at 11:33 PM, Corey Frang gnar...@gmail.com wrote:
Just to provide another way of working around it:
var empty = {}; // or even a symbol?
function splice(start = empty,
On Nov 11, 2013, at 6:10 AM, Mark S. Miller wrote:
That is excellent! Has all the upsides of the best of the other proposals and
none of the downsides.
On Sun, Nov 10, 2013 at 11:33 PM, Corey Frang gnar...@gmail.com wrote:
Just to provide another way of working around it:
var empty =
On Mon, Nov 11, 2013 at 9:21 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Nov 11, 2013, at 6:10 AM, Mark S. Miller wrote:
On Sun, Nov 10, 2013 at 11:33 PM, Corey Frang gnar...@gmail.com wrote:
Just to provide another way of working around it:
var empty = {}; // or even a symbol?
Doh! My mistake. I was momentarily attributing the old semantics to default
parameter assignment, in which case we wouldn't have had the problem in the
first place.
On Mon, Nov 11, 2013 at 9:21 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Nov 11, 2013, at 6:10 AM, Mark S. Miller
On Nov 10, 2013, at 6:12 PM, Boris Zbarsky wrote:
...
I believe even for all of these, we could treat them as overloads on the
type of some argument, where we allow undefined as a type that matches
the argument not being present or an argument being optional.
So a viable way forward
On 11/11/13 1:37 PM, Allen Wirfs-Brock wrote:
My, perhaps more radical, recommendation would be to only do overloading based
upon argument counts and to treat all type overloads for a given argument
length as union types that are left to a function's implementation to
discriminate.
We could
I hate to bring this up, as I'm sure I've missed a bunch of the arguments
that define WHY, but if this is the case, it seems unintuitive to me that
passing undefined still results in a default param being set.
function test(a = 1) { console.log(a); }
test(); // gets 1 - yay
test(undefined); //
On 11/11/2013 11:31 AM, Corey Frang wrote:
I hate to bring this up, as I'm sure I've missed a bunch of the
arguments that define WHY, but if this is the case, it seems
unintuitive to me that passing undefined still results in a default
param being set.
function test(a = 1) { console.log(a);
Sure, it makes some sense when you see it like that :)
I retract my this doesn't make sense
I guess we are stuck with (...args)
On Mon, Nov 11, 2013 at 2:37 PM, Brandon Benvie bben...@mozilla.com wrote:
On 11/11/2013 11:31 AM, Corey Frang wrote:
I hate to bring this up, as I'm sure I've
One of the the few remaining uses of a function's 'arguments' binding is to
determine the actual number of passed arguments. This is necessary in some
overloading scenarios where a function has different behavior when an argument
is completely absent then it has when undefined (or any other
1) # is one of the few ascii characters we haven't used up yet. Let's not
use it up on a minor convenience.
2) Introducing new syntax for use cases that are expected to be frequent,
e.g., classes, often pays for its weight. The frequency makes it likely
that readers will understand what it is the
Interesting, unless we haven't `...rest` already. Otherwise, sounds as an
overhead (and really just a workaround to fix a particular issue, but not a
very useful language construct) to me. Since in the ES6 world, if a
function is designed to work with variant number of arguments, this should
On the other hand, we are this close in ES6 to relieveing people from
having to use arguments at all.
I like the intention behind Allen's idea. To defend the concrete syntax
a bit, one would argue that only the final formal parameter may be
prefixed with #, and we are free to use # in other
On Nov 10, 2013, at 10:52 AM, Mark S. Miller wrote:
1) # is one of the few ascii characters we haven't used up yet. Let's not
use it up on a minor convenience.
But this is a very restrictive context. It isn't clear that it would impact
any other possible usage.
Allen
On Nov 10, 2013, at 11:08 AM, Brendan Eich wrote:
On the other hand, we are this close in ES6 to relieveing people from having
to use arguments at all.
I like the intention behind Allen's idea. To defend the concrete syntax a
bit, one would argue that only the final formal parameter may
Le 10/11/2013 19:12, Allen Wirfs-Brock a écrit :
One of the the few remaining uses of a function's 'arguments' binding
is to determine the actual number of passed arguments. This is
necessary in some overloading scenarios where a function has different
behavior when an argument is completely
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of David
Bruant
Why creating something new if it's only encouraging a bad practice? Is there
a good use case?
+1. I thought we were trying to make `undefined` and not passed equivalent.
Adding a feature specifically designed
Hi Brendan and Allen, you are both responding only to my point #1. I
consider my point #2 --- cognitive load of the reader on encountering a
rarely seen construct --- to be the more significant criticism here.
On these grounds, your
function f(args: x, y, z) {
is worse. Given how : is
Also
function f(args: x, y, z) {
will suggest to TypeScript readers that the parameter args has type x.
On Sun, Nov 10, 2013 at 11:44 AM, Mark S. Miller erig...@google.com wrote:
Hi Brendan and Allen, you are both responding only to my point #1. I
consider my point #2 --- cognitive
I would rather think about a smart syntax able to tell the function it
should expose arguments as it was before.
`function splice:arguments(start, deleteCount, ...items)`
or
`function splice:args(start, deleteCount, ...items)`
or anything different that looks reasonable ? Or maybe not useful
Good point - between that and your previous message, I withdraw the label idea.
/be
Sent from my iPhone
On Nov 10, 2013, at 7:47 PM, Mark S. Miller erig...@google.com wrote:
Also
function f(args: x, y, z) {
will suggest to TypeScript readers that the parameter args has type x.
The other objection is that counting top level commas misleads.
/be
On Nov 10, 2013, at 7:21 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The use of : suggests that another alternative could be:
function splice(start, deleteCount, ...items, :argCount) {
but I still lie #
On Nov 10, 2013, at 11:44 AM, Mark S. Miller wrote:
Hi Brendan and Allen, you are both responding only to my point #1. I consider
my point #2 --- cognitive load of the reader on encountering a rarely seen
construct --- to be the more significant criticism here.
Hence my choice of using #
I don’t fully understand this — what is the reason for needing to know actual
argument count? The historical reason was that if i have a var arg function
with a few required parameters i don’t have any nice way of iterating the
optional args.
Default and rest parameters seem to solve this use
Does this become common for those using DOM APIs or for those implementing
DOM APIs? If only the latter, well...
I want to retire arguments as well. For these rare cases, I would use the
patterns involving Combining ... with destructuring patterns in
the body ain't too bad.
And introducing
Sorry, ignore the line noise I just remembered that we decided to treat
undefined as missing.
I do recall actually making the argument w.r.t defaults, that treating
undefined as “not provided” would cause us difficulty if anyone ever wanted to
distinguish undefined from not provided.
—Oliver
On Nov 10, 2013, at 12:52 PM, Oliver Hunt wrote:
I don’t fully understand this — what is the reason for needing to know actual
argument count? The historical reason was that if i have a var arg function
with a few required parameters i don’t have any nice way of iterating the
optional
On Nov 10, 2013, at 12:53 PM, Mark S. Miller wrote:
Does this become common for those using DOM APIs or for those implementing
DOM APIs? If only the latter, well...
I want to retire arguments as well. For these rare cases, I would use the
patterns involving Combining ... with
fwiw, I have few APIs that use null or undefined / void 0 as explicit
action to remove an item ... an example.
```javascript
function cookie(key, value) {
if (arguments.length === 1) return get(key);
if (value == null) return del(key);
set(key, value);
return value;
}
```
Although I
On Nov 10, 2013, at 9:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Not sure why this is so needed though.
Allen's posts make the case: webidl and varargs-style functions. Not all legacy.
/be
___
es-discuss mailing list
Le 10/11/2013 22:19, Brendan Eich a écrit :
On Nov 10, 2013, at 9:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
Not sure why this is so needed though.
Allen's posts make the case: webidl and varargs-style functions. Not all legacy.
WebIDL creates spec, not code. The language
The mere fact the this discussion is coming up, is a good argument (to me
anyway) that default parameter behaviour should have been in terms of argument
count, not |undefined|. Again, sentinel values that are regular valid values
are a bad thing.
I still cannot recall what the usage scenario
On Sun, Nov 10, 2013 at 1:08 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Nov 10, 2013, at 12:53 PM, Mark S. Miller wrote:
Does this become common for those using DOM APIs or for those implementing
DOM APIs? If only the latter, well...
I want to retire arguments as well. For these
Le 10/11/2013 22:30, K. Gadd a écrit :
JSIL and embind both need arguments.length for efficient method call
dispatch when dealing with overloaded functions. Is it your intent
that all such scenarios must now pay the cost of creating an array (to
hold the rest arguments) and then destructuring
On Nov 10, 2013, at 9:24 PM, David Bruant bruan...@gmail.com wrote:
WebIDL creates spec, not code. The language syntax doesn't need to evolve for
that.
Wrong, webidl and jsidl (and jsil and embind) are both interface and a bit of
implementation. Testing argc != testing sentinel value. Two
On Sun, Nov 10, 2013 at 1:30 PM, K. Gadd k...@luminance.org wrote:
JSIL and embind both need arguments.length for efficient method call
dispatch when dealing with overloaded functions. Is it your intent that all
such scenarios must now pay the cost of creating an array (to hold the rest
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
On Nov 10, 2013, at 1:08 PM, Allen Wirfs-Brock wrote:
On Nov 10, 2013, at 12:53 PM, Mark S. Miller wrote:
Does this become common for those using DOM APIs or for those implementing
DOM APIs? If only the latter, well...
I want to retire arguments as well. For these rare cases, I would
Le 10/11/2013 22:42, Brendan Eich a écrit :
On Nov 10, 2013, at 9:24 PM, David Bruant bruan...@gmail.com wrote:
WebIDL creates spec, not code. The language syntax doesn't need to evolve for
that.
Wrong, webidl and jsidl (and jsil and embind) are both interface and a bit of
implementation.
I think I've completely missed the `undefined === absent` conversation ...
so if I have an object, and `obj.key = void 0` why `key` would be
considered absent, exactly? `undefined` is a very well described value,
passing stuff around thinking has a value but getting ignored by signatures
and who
Dispatching entirely off argument types and not anything else (like count)
is an interesting idea. I'm not sure it's on topic for this discussion
though. Is there a way to actually do type dispatch in ES at present, let
alone efficiently?
Based on my understanding of current VMs, you'd have to do
On Nov 10, 2013, at 2:12 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I think I've completely missed the `undefined === absent` conversation ... so
if I have an object, and `obj.key = void 0` why `key` would be considered
absent, exactly? `undefined` is a very well described
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
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 should just use the
I hate arguments.length as well. But given that we can't get rid of it, the
occasional idiomatic use is not *that* vexing. In strict mode arguments
is effectively a reserved word. If the only use of arguments within a
strict function is arguments.length, this will be visible both to humans
and to
void 0 is identical to undefined, I perfectly know it, and I have no idea
who decided that undefined === absent ..
```
alert(absent); // this is error
alert(undefined); // this is undefined
var undefined;
```
I think ignoring undefined, if that's what has been decided, is a mistake.
As easy
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
On Sun, Nov 10, 2013 at 2:53 PM, Brendan Eich bren...@mozilla.com wrote:
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:
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
You replied as if I took part in those conversations and forgot ... that
might be the case but AFAIK (indeed) is not.
However, I am not saying that explicit undefined should not result in the
default argument value, when specified, I am saying that passing explicitly
undefined should not be
From: Allen Wirfs-Brock al...@wirfs-brock.com
One of the the few remaining uses of a function's 'arguments' binding is
to determine the actual number of passed arguments. This is necessary in
some overloading scenarios where a function has different behavior when an
argument is completely absent
On Nov 10, 2013, at 3:31 PM, Benjamin (Inglor) Gruenbaum wrote:
From: Allen Wirfs-Brock al...@wirfs-brock.com
One of the the few remaining uses of a function's 'arguments' binding is to
determine the actual number of passed arguments. This is necessary in some
overloading scenarios where a
Couldn’t this be handled by pattern matching? Two steps would be necessary to
do so (I know that the second one is controversial, but hear me out).
First: introduce a pattern matching construct.
```js
function splice(...args) {
match(args) {
case [start, stop, ...item]:
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
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
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
On Nov 10, 2013, at 4:53 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I think the only sort of declarative overloading that is appropriate for JS
is based upon the number of actually passed arguments (and nothing else).
Not to pick a fight (yet), but that's a bit strong. Recall I'm
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
On 11/10/13 5:12 PM, Andrea Giammarchi wrote:
I think I've completely missed the `undefined === absent` conversation
... so if I have an object, and `obj.key = void 0` why `key` would be
considered absent, exactly?
Fwiw, based on feedback from this group this is how WebIDL dictionaries
work
On 11/10/13 8:25 PM, Allen Wirfs-Brock wrote:
Where the usual attempts at describing overloads for JS go wrong is it they
either ignore dynamic coercions or forget in in real JS code they would happen
after the overload selection. WebIDL address this by building performing
(known) coercions
On Mon, Nov 11, 2013 at 2:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
One of the the few remaining uses of a function's 'arguments' binding is to
determine the actual number of passed arguments. This is necessary in some
overloading scenarios where a function has different behavior
Just to provide another way of working around it:
var empty = {}; // or even a symbol?
function splice(start = empty, count = 0, ...items) {
if (start === empty) { ...
}
On Mon, Nov 11, 2013 at 1:22 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 11, 2013 at 2:12 AM, Allen
72 matches
Mail list logo
