missing non-rest_parameters should throw error
http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters
Hi,
Here is the behavior I would like:
function f( a, b, ...rest ) { }
f( 1, 1 );// ok
f( 1, 1, 1 );// ok
f( 1, undefined );// ok
f( 1 );// Error: missing parameter
Because since you can't reference a and b as properties of an object
anymore, there is no way you can know whether they are undefined
because the value given was undefined or because no value was given.
Of course, no such error would happen if there is a default value:
function f( a, b=1, ...rest ) { }
---
If you consider throwing an error a bit too harsh, you should consider
giving arguments.length. Not withing arguments but as a separate
variable.
function f( a, b, ...rest ) {
var awesomeNameYoullFind = f.length + rest.length; // this should
be provided by core
if ( awesomeNameYoullFind 2 ) {// and people who want to throw
errors will have a convenient way of doing it
throw Error();
}
}
-
Another thing I think arguments shouldn't disappear. It sucks that it
isn't an array but it still has some use-cases.
e.g. a function that delegates in certain conditions
function f( a, b, ...rest ) {
if ( a ) {
f2.apply( this, arguments );
// or f2( ...arguments );
} else {
// w/e
}
}
This could be done that way:
function f( a, b, ...rest ) {
if ( a ) {
f2( a, b, ...rest );
} else {
// w/e
}
}
But what if you have a, b, c, d and so on? You don't want to copy all
those variable names.
And what if you want to delegate everything except a and b? Without an
argu,ments object, it's bothersome. With it, you just slice from index
2...
To give a real example: assertions.
I use to do things like that:
function f( a, b, c, d ) {
assertArguments( arguments, [
{// a
type: 'number'
},
{// b and c
type: 'string',
length: 2
},
{// d
type: 'object',
optionnal: true
}
] );
}
And if you remove the arguments object, it gets really bothersome...
You have to make sure you pass every single arguments in the good
order...
But of course, it should become a real array (and probably change its
name to args or something similar). And to prevent from breaking
existing codes, if there is already a variable named args in the scope
or a parent scope *and it is not the args created for another
function*, replace it.
var args = 1;
function f( ) {
// here args is 1 no matter what
}
f(0);
function f1( ) {
// here args is the arguments from f1
function f2( ) {
// here args is the arguments from *f2*
// because even though it was in the scope, some magic
happened and the engine figured out it wasn't a variable declared by
the user
}
f2(2);
}
f1(1);
PS: If a new arguments object is created, then there is no use for
awesomeNameYoullFind.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: missing non-rest_parameters should throw error
I am not sure I am missing something but I think arguments could disappear
without problems, being easily simulated like this:
function f1(...arguments) {
f2.apply(this, arguments);
f2(...arguments);
let [a,b,c,...rest] = arguments;
// etc etc
}
Am I wrong ?
br
On Wed, Oct 26, 2011 at 6:07 PM, Xavier MONTILLET
xavierm02@gmail.comwrote:
http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters
Hi,
Here is the behavior I would like:
function f( a, b, ...rest ) { }
f( 1, 1 );// ok
f( 1, 1, 1 );// ok
f( 1, undefined );// ok
f( 1 );// Error: missing parameter
Because since you can't reference a and b as properties of an object
anymore, there is no way you can know whether they are undefined
because the value given was undefined or because no value was given.
Of course, no such error would happen if there is a default value:
function f( a, b=1, ...rest ) { }
---
If you consider throwing an error a bit too harsh, you should consider
giving arguments.length. Not withing arguments but as a separate
variable.
function f( a, b, ...rest ) {
var awesomeNameYoullFind = f.length + rest.length; // this should
be provided by core
if ( awesomeNameYoullFind 2 ) {// and people who want to throw
errors will have a convenient way of doing it
throw Error();
}
}
-
Another thing I think arguments shouldn't disappear. It sucks that it
isn't an array but it still has some use-cases.
e.g. a function that delegates in certain conditions
function f( a, b, ...rest ) {
if ( a ) {
f2.apply( this, arguments );
// or f2( ...arguments );
} else {
// w/e
}
}
This could be done that way:
function f( a, b, ...rest ) {
if ( a ) {
f2( a, b, ...rest );
} else {
// w/e
}
}
But what if you have a, b, c, d and so on? You don't want to copy all
those variable names.
And what if you want to delegate everything except a and b? Without an
argu,ments object, it's bothersome. With it, you just slice from index
2...
To give a real example: assertions.
I use to do things like that:
function f( a, b, c, d ) {
assertArguments( arguments, [
{// a
type: 'number'
},
{// b and c
type: 'string',
length: 2
},
{// d
type: 'object',
optionnal: true
}
] );
}
And if you remove the arguments object, it gets really bothersome...
You have to make sure you pass every single arguments in the good
order...
But of course, it should become a real array (and probably change its
name to args or something similar). And to prevent from breaking
existing codes, if there is already a variable named args in the scope
or a parent scope *and it is not the args created for another
function*, replace it.
var args = 1;
function f( ) {
// here args is 1 no matter what
}
f(0);
function f1( ) {
// here args is the arguments from f1
function f2( ) {
// here args is the arguments from *f2*
// because even though it was in the scope, some magic
happened and the engine figured out it wasn't a variable declared by
the user
}
f2(2);
}
f1(1);
PS: If a new arguments object is created, then there is no use for
awesomeNameYoullFind.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: missing non-rest_parameters should throw error
1) arguments is needed for backwards compatability (no migration tax)
2) it is useful with destructing parameters:
function ({a,b,c}, [x,y]) {
if (arguments.length 2) ...
...
var arg1obj = argruments[0];
...
Sent from Samsung tablet___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
testable specification
According to http://wiki.ecmascript.org/doku.php?id=harmony:harmony goal #2 of Harmony is: Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. Is there much activity toward this goal? The current ES6 drafts are using mostly the same formalism as ES1 (although there was a marked de-spaghettification between ES3 and ES5). (I ask because, in my spare time, I'm developing a process that massages the ES spec into an executable/testable form. So I wonder if I'm duplicating existing work.) -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: testable specification
On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote: According to http://wiki.ecmascript.org/doku.php?id=harmony:harmony goal #2 of Harmony is: Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. Is there much activity toward this goal? The current ES6 drafts are using mostly the same formalism as ES1 (although there was a marked de-spaghettification between ES3 and ES5). My opinion is that the best we'll do on this goal, better than past ECMA-262 specs, is the http://test262.ecmascript.org/ project. I.e., we have a testsuite and it will be maintained and extended. (I ask because, in my spare time, I'm developing a process that massages the ES spec into an executable/testable form. So I wonder if I'm duplicating existing work.) Interesting -- you are writing an interpreter? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: testable specification
Michael, It took me a while to find them the first time I looked, but they are downloadable here: http://hg.ecmascript.org/tests/test262/ Instructions here: http://wiki.ecmascript.org/doku.php?id=test262:command On Wed, Oct 26, 2011 at 6:37 PM, Brendan Eich bren...@mozilla.com wrote: On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote: According to http://wiki.ecmascript.org/doku.php?id=harmony:harmony goal #2 of Harmony is: Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. Is there much activity toward this goal? The current ES6 drafts are using mostly the same formalism as ES1 (although there was a marked de-spaghettification between ES3 and ES5). My opinion is that the best we'll do on this goal, better than past ECMA-262 specs, is the http://test262.ecmascript.org/ project. I.e., we have a testsuite and it will be maintained and extended. (I ask because, in my spare time, I'm developing a process that massages the ES spec into an executable/testable form. So I wonder if I'm duplicating existing work.) Interesting -- you are writing an interpreter? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: testable specification
Brendan Eich wrote: On Oct 26, 2011, at 12:08 PM, Michael Dyck wrote: According to http://wiki.ecmascript.org/doku.php?id=harmony:harmony goal #2 of Harmony is: Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. Is there much activity toward this goal? The current ES6 drafts are using mostly the same formalism as ES1 (although there was a marked de-spaghettification between ES3 and ES5). My opinion is that the best we'll do on this goal, better than past ECMA-262 specs, is the http://test262.ecmascript.org/ project. I.e., we have a testsuite and it will be maintained and extended. Certainly a laudable effort. (I ask because, in my spare time, I'm developing a process that massages the ES spec into an executable/testable form. So I wonder if I'm duplicating existing work.) Interesting -- you are writing an interpreter? Yes, but not an interpreter for ES, rather an interpreter (more or less) for ES-spec-ese, the ad hoc notation that the ES spec's algorithms are written in. So then if you feed the ES spec to *that* interpreter, you do get an interpreter for ES. That's the idea, anyhow. It works, but so far only for really simple programs. -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: testable specification
Rick Waldron wrote: Michael, It took me a while to find them the first time I looked, but they are downloadable here: http://hg.ecmascript.org/tests/test262/ Instructions here: http://wiki.ecmascript.org/doku.php?id=test262:command Yup, I'm aware of the test262 project -- I even submitted a bug against it. And it's great that ES has a test suite. But from the context of the goal: Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. I got the impression that testable specification meant that one would actually test the specification, not just test implementations of it. Anyhow, that's the kind of activity I was asking about in my original post. -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: testable specification
On Oct 26, 2011, at 5:02 PM, Michael Dyck wrote: (I ask because, in my spare time, I'm developing a process that massages the ES spec into an executable/testable form. So I wonder if I'm duplicating existing work.) Interesting -- you are writing an interpreter? Yes, but not an interpreter for ES, rather an interpreter (more or less) for ES-spec-ese, the ad hoc notation that the ES spec's algorithms are written in. Right, our Visual Cobol, as it were ;-). So then if you feed the ES spec to *that* interpreter, you do get an interpreter for ES. That's the idea, anyhow. It works, but so far only for really simple programs. This could indeed satisfy the goal! Great to hear you are working on it. How is it going? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
