What about functions that take two or more independent optional arguments,
where sometimes you want to omit the first argument while providing the second?
For example, in the ECMAScript Internationalization API:
Intl.Collator = function(localeList, options) { ... }
currently fills in
This is covered on the wiki too.
http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
On Thu, Apr 12, 2012 at 20:38, Russell Leggett
russell.legg...@gmail.com wrote:
The examples cited are arguably cases where the built-in behaviour is
unintuitive to many JavaScript
On Thu, Apr 12, 2012 at 4:11 PM, gaz Heyes gazhe...@gmail.com wrote:
On 12 April 2012 14:51, Lasse Reichstein reichsteinatw...@gmail.com wrote:
On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes gazhe...@gmail.com wrote:
function true(){alert('Call me');};
Is this a deliberate Mozilla change, or
On 13 April 2012 08:38, Lasse Reichstein reichsteinatw...@gmail.com wrote:
I guess that depends on the version. I was testing in Firefox 9.0.1,
and it runs your function.
Ah I'm testing on FF11 if it works on your version then it's a valid answer
:)
On Thu, Apr 12, 2012 at 8:53 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I think we should stick with the ES5 intent (Unicode escapes don't change the
meaning of an IdentiferName, including keywords) and possibly clarify the Es6
spec. language to make this intent even clearer.
I.e.,
Le 13/04/2012 01:36, Brandon Benvie a écrit :
With Direct Proxies there's no such thing as a fully virtual object.
Virtualized objects can be achieved by just creating a new
empty/placeholder object with the desired invariants ([[prototype]],
[[class]], etc). This is all well and good except
Fwiw, arguments.length is currently the _only_ way of properly
detecting the correct number of explicit variables of _any_ type. I
would hate for that behavior to change in the case of explicitly
passing on undefined.
Default values of course do need to be set in the arguments array so
it's
On 12 April 2012 15:37, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Right chrome and safari log undefined in that case. FF and IE9 syntax
error out on the var declaration.
As long as we're exploring web compat, here's a historical view of
SpiderMonkey behaviour --
JS 1.8.5 (~ Firefox 4)
Some time after Firefox 4, a fix went in so we match ES5:
js fals\u0065
false
js
/be
Wes Garland wrote:
On 12 April 2012 15:37, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
Right chrome and safari log undefined in that case. FF and IE9
syntax error
I wonder if, with the concise method notation for literals (and possibly class
declarations), one couldn’t introduce three modes of accessing a property: Read
(getter), write (setter) and call (call interceptor?).
- Manually assigned functions: everything works as it does now.
- Concise method
If you really need to know how many arguments were passed just use rest
parameters.
We should definitely not add more API to the arguments object.
On Apr 13, 2012 1:34 AM, Peter van der Zee e...@qfox.nl wrote:
Fwiw, arguments.length is currently the _only_ way of properly
detecting the correct
On 13 April 2012 16:47, Brendan Eich bren...@mozilla.org wrote:
Some time after Firefox 4, a fix went in so we match ES5:
js fals\u0065
false
js
Hm, I still don't quite see where ES5 would specify this behaviour.
The relevant bits I can find are:
- In 5.1.6: Terminal symbols of the lexical,
On Apr 13, 2012, at 8:19 AM, Andreas Rossberg wrote:
On 13 April 2012 16:47, Brendan Eich bren...@mozilla.org wrote:
Some time after Firefox 4, a fix went in so we match ES5:
js fals\u0065
false
js
Hm, I still don't quite see where ES5 would specify this behaviour.
The relevant bits I
On Apr 12, 2012, at 7:31 PM, Luke Hoban wrote:
...
This is a good way of explaining the proposed semantics, but...
But I see why somebody calling a function defined as function(a={ }){...}
explicitly as f(undefined) would expect to trigger the default value
initializer.
Right.
On Fri, Apr 13, 2012 at 12:26 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Apr 12, 2012, at 7:31 PM, Luke Hoban wrote:
...
This is a good way of explaining the proposed semantics, but...
But I see why somebody calling a function defined as function(a={ }){...}
explicitly as
On Apr 12, 2012, at 8:38 PM, Russell Leggett wrote:
At first the answer to this didn't really matter to me, because how often
does someone pass undefined to a function like foo(undefined). I know I
don't, though I'm sure it happens occasionally. Then I thought about it and
realized
I'd write it:
function fadeToggle(...args){
if(visible){
fadeOut(...args);
}else{
fadeIn(...args);
}
}
If you don't care about the the actual argument values are just passing
them on that's how you should do it.
Ok,
On Apr 12, 2012, at 11:25 PM, Norbert Lindenberg wrote:
What about functions that take two or more independent optional arguments,
where sometimes you want to omit the first argument while providing the
second?
arguably, this is where you should be using an options argument rather than
Allen Wirfs-Brock wrote:
On Apr 12, 2012, at 11:25 PM, Norbert Lindenberg wrote:
What about functions that take two or more independent optional arguments,
where sometimes you want to omit the first argument while providing the second?
arguably, this is where you should be using an
It’s an interesting case of “traditional lenient style” versus “new, more
strict style”. Both approaches have merit (pro leniency: familiarity,
compatibility). With arity checking, a first step towards the latter style has
been made, I think it makes sense to continue in that direction.
On Apr
On Apr 13, 2012, at 10:10 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Apr 12, 2012, at 11:25 PM, Norbert Lindenberg wrote:
What about functions that take two or more independent optional
arguments, where sometimes you want to omit the first argument while
providing the
On Apr 13, 2012, at 10:53 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2012, at 10:10 AM, Brendan Eich wrote:
In general, delegation (depth D) plus optionality (degree N paramters) makes
an (2N)^D worst-case combinatorial explosion.
This is IMHO a strong argument for a sentinel in-language to
On Apr 13, 2012, at 9:38 AM, Russell Leggett wrote:
Yes, but as I said, and Erik pointed out is in the wiki, it is a lot more
likely that someone would pass f(foo) or f(obj.foo) where foo might be
undefined.
Bingo.
Expecting undefined as a possible valid argument (as opposed to a missing
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
foo(undefined);
foo(3);
foo(undefined, undefined);
foo(undefined, 3);
foo(3, undefined);
Default values are for when arguments are not passed, it does not make logical
sense to say that they're the value
Making default values overridden by undefined makes them useless in a large
portion of cases, but not doing so makes arguments.length a liar and
invalidates other cases.
___
es-discuss mailing list
es-discuss@mozilla.org
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
foo(undefined);
1, 2, 1
foo(3);
3, 2, 1
foo(undefined, undefined);
1, 2, 2
foo(undefined, 3);
1, 3, 2
foo(3, undefined);
3, 2, 2
On Apr 13, 2012, at 11:46 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2012, at 11:22 AM, David Herman wrote:
On Apr 13, 2012, at 10:53 AM, Allen Wirfs-Brock wrote:
That sentinel could simply be a empty argument position:
new Intl.Collator( , {usage: search});
That's not enough. It
On Apr 13, 2012, at 11:51 AM, Allen Wirfs-Brock wrote:
both sides of this debate seem a little smelly. But, Pretending that
undefined isn't a real value seems more smelly to me.
There's no need to think of it as pretending it's not a real value. Think of it
as saying that the undefined value
On Apr 13, 2012, at 11:48 AM, David Herman wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
Oops: 1, 2, 0
Dave
___
es-discuss mailing
On Apr 13, 2012, at 11:48 AM, David Herman dher...@mozilla.com wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
foo(undefined);
1, 2, 1
Uh what? I pass no arguments and
I'm sympathetic toward `undefined` as a sentinel for no value of the expected
type, whereas `null` means we have a value of the expected type, but that
value represents 'nothing.' Not sure if anyone else sees it that way, though,
and admittedly it's based on vague hand-wavey arguments.
David Herman wrote:
Think of it as saying that the undefined value is the idiomatic way in JS to represent
no value for the expected type. The smelly thing then is to create API's that
both use defaults and accept undefined as a valid input.
FTR, I'm on board with Arv, Dave, Russell, and
On Fri, Apr 13, 2012 at 3:05 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 13, 2012, at 11:48 AM, David Herman dher...@mozilla.com wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
On Fri, Apr 13, 2012 at 12:00 PM, David Herman dher...@mozilla.com wrote:
On Apr 13, 2012, at 11:51 AM, Allen Wirfs-Brock wrote:
both sides of this debate seem a little smelly. But, Pretending that
undefined isn't a real value seems more smelly to me.
There's no need to think of it as
The story for JS is
undefined is no value
null is no object
It's definitely a just-so story, and some listeners want their money
back, but we're stuck with two. For defaulting, undefined is the only
choice of an in-language sentinel you can express. No one wants to add
yet another bottom
On Apr 13, 2012, at 12:05 PM, Oliver Hunt wrote:
On Apr 13, 2012, at 11:48 AM, David Herman dher...@mozilla.com wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
foo(undefined);
1, 2, 1
Uh what? I pass no arguments and arguments.length is 2, and i pass one
argument and
Argh, I've caught Allen's dropped-negative disease:
Brendan Eich wrote:
I would be surprised if people wrote
function foo(a = default_a) {...}
and wanted
foo(undefined)
to bind default_a to a.
s/wanted/not want/
or else s/bind default_a to a/bind undefined to a/.
Will proofread
On Apr 13, 2012, at 12:16 PM, Brendan Eich wrote:
The story for JS is
undefined is no value
null is no object
Yet there are many places in the language where undefined is not the same as no
value. For example:
let mapped1 = [,,foo,,].map(v=v+1);
let mapped2
On Apr 13, 2012, at 12:16 PM, Brendan Eich wrote:
...
No one wants to add yet another bottom type and singleton value.
Permitting holes in argument lists, eg Intl.Collator( , {usage:search})
doesn't require either at the user language level or the specification level.
Whether a sentinel
Allen Wirfs-Brock wrote:
Making f() and f(undefined) mean the something (but only sometimes, you have to
look at the actual implementation of f to know for sure) seems to be add just
another internal inconsistency that makes it harder to form a general
conceptual model of the language.
This
On Apr 13, 2012, at 8:19 AM, Andreas Rossberg wrote:
- Going on, the spec says All interpretations of identifiers within
this specification are based upon their actual characters regardless
of whether or not an escape sequence was used to contribute any
particular characters.
Looking
On Apr 13, 2012, at 23:40 , Brendan Eich wrote:
You mean automatic binding with memoization on read, I hope.
Otherwise you break o.m === o.m.
That makes sense, yes.
This can be implemented with accessors and weakmaps, of course. That says two
things to me:
1. It ain't cheap so should
On Fri, Apr 13, 2012 at 5:42 PM, Brendan Eich bren...@mozilla.org wrote:
Sam has similar testimony from Racket (neé PLT-Scheme).
Very much so -- I've encountered places where Racket's semantics for
keyword arguments (which is similar to what Allen proposes for ES6)
ends up causing the entire set
We should really use ''new Name'' instead of ''create''.
import {Name} from '@name';
let myName = new Name;
instead of
module name = '@name';
let myName = name.create();
JS has dedicated syntax for creating new objects. Lets use that. There
is also no precedence for ''create'' functions in JS.
Erik Arvidsson wrote:
We should really use ''new Name'' instead of ''create''.
import {Name} from '@name';
let myName = new Name;
instead of
module name = '@name';
let myName = name.create();
+1 from me.
JS has dedicated syntax for creating new objects. Lets use that. There
is also no
+1
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Apr 10, 2012 at 4:01 PM, Axel Rauschmayer a...@rauschma.de wrote:
What is a good term for functions that don’t have/use dynamic `this`?
“Non-method function” defines them by what they aren’t, I would like a
positive definition. I’ve considered the term “pure function”, but the
47 matches
Mail list logo
