[[Get]] and GetValue can return Reference Type
This issue is derived from Esprima issue 81
http://code.google.com/p/esprima/issues/detail?id=81
Hello everyone,
According to the ECMA262 5.1th, [[Call]] of host object may return
Reference Type.
So, all values using raw [[Call]] result may be Reference Type.
For example, [[Get]] may return Reference Type if *getter* is a host object
that [[Call]] returns Reference Type.
http://ecma-international.org/ecma-262/5.1/#sec-8.12.3
As the result, GetValue may return Reference Type because that use result
value of [[Get]]
http://ecma-international.org/ecma-262/5.1/#sec-8.7.1
And, for example, if we define getter of object, getter function is host
object that [[Call]] return Reference Type,
(10, obj.getter)
returns Reference type, so,
(10, obj.getter) = 10;
is valid because GetValue is performed, but GetValue result is also
Reference Type.
In the ECMA262 5.1th, GetValue is assumed that doesn't return Reference
Type, for exmaple,
var obj = {
get v() {
// this v function is host object and returns Reference;
// we can define this v using host object and defineProperty
return Reference;
}
};
And,
typeof obj.v
Then, typeof should treat Reference Type also, but in 11.4.3, Reference
Type is not considered.
http://ecma-international.org/ecma-262/5.1/#sec-11.4.3
I think this is a bug of spec and GetValue and [[Get]] should not return
Reference type, is it right?
To fix this, I think following 3 way are good.
1. perform GetValue on [[Call]] result in the spec
2. re-define [[Get]] and GetValue can return Reference Type. This needs
to re-define all the spec part using [[Get]], GetValue and others
3. remove feature that [[Call]] can return Reference Type
Because all modern engines don't consider that [[Call]] result is Reference
and this feature makes big performance-regression, personally I think 3 is
better.
Regards,
Yusuke Suzuki
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Tue, Jun 12, 2012 at 9:17 AM, Brendan Eich bren...@mozilla.org wrote: Mark S. Miller wrote: On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eichbren...@mozilla.org wrote: Also, as you pointed out, even error.stack leaks information. Where do you draw the line? Conservatively. I suggest that there be no error.stack, but rather getStack(error), in order to avoid this information leak. With some kind of import getStack from @reflect; or similar, and SES uses a custom loader to censor @reflect? Yes, that's the kind of thing I have in mind. Perhaps an @privileged? This is a matter of preference, not necessity, if we're talking about the language as it is. We won't be making use strict the default. We are trying to avoid more modes (1JS). We're not talking about SES. So I don't see how it can be argued logically that a non-strict-only arguments-disclosing stack-tracing API is either never helpful nor always helpful. YMMV. I'm not yet arguing that or the opposite, rather, I'm confused about what non-strict-only means in this context. Actual stacks consist of a mixture of strict and non-strict activations. How would the proposed API deal with that? I see -- thanks. We should try to detail the privileged APIs and their module(s) a bit more. I used @reflect above but I didn't mean to equate it to Tom's Reflect.* used in conjunction with direct proxies. And not all reflection facilities are privileged -- more the reverse for the direct proxy stuff, right? yup. JS is an amazingly reflective language. We've taken care in both the ES5 and ES6 efforts that all reflective operations uphold the ocap security of strict functions -- so far without needing a special @privileged module. getStack and makeWeakRef are the first reflective operations that do require some such privilege separation. Given an @privileged module and a desire to inspect the arguments of non-strict activations, we should consider whether @privileged should also grant the ability to inspect the arguments of strict activations. Is @privileged per global context (frame)? If so, does it only provide privileges over objects from that same global context? Or is it more like browser chrome js vs page js, where special chrome privileges apply to all page js objects it encounters? Might we eventually standardize a module that provides all the privileges needed to implement a portable debugger? Is it appropriate for the language to define multiple kinds of privilege-granting modules, or should the language delegate this to the host? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add basic arithmetic to Math
On Jun 11, 2012 6:18 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 10, 2012, at 11:48 AM, Angus Croll wrote: Rationale: Some functional JavaScript idioms are hamstrung by the lack of native basic arithmetic functions. Would be handy/elegant/instructive to be able to write arr.reduce(Math.add); Moreover having functional versions of arithmetic operators would improve the currying/partial/composition experience. Caveats: 1. Arrow functions work pretty well too: arr.reduce((a,b)=a+b); These seems better, non-invasive approach rather than than adding built-in functions corresponding to every built-in operator. Also, nothing preventing somebody from creating a library of such functions. https://github.com/gkz/prelude-ls, also supports currying which is quite useful 2. If add and multiply accepted multiple args, reduce would not be necessary for these cases: Math.add.apply(null, arr); Math.add(...arr) Allen ___ 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: Error stack
On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick
char...@isomorphic.com wrote:
On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller erig...@google.com wrote:
On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
char...@isomorphic.com wrote:
I'm reading this as saying that stack traces in general should not be
available unless the code is privileged in some way. This can't be
what you mean, so could you clarify?
That is exactly what I mean.
The only way I can see this working is if there is a way for a given
piece of code to trap an error and ask some kind of (elevated
privilege) logging system to provide diagnostic information that a
(privileged) end user can see.
I'm not sure what you mean by trap to an error, but the rest of your
description seems close to how SES's console.log, console.warn, etc
work. They are endowed with access to the privileged getStack function
and use it to display stack traces on the console's output. See
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#28
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#157
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js#116
We assume that unprivileged code generally has no way to read the
console's output.
It also seems like, in addition to
this, you should be able to get to stack information programmatically
so long as you stay within your module or modules that have the same
privilege.
If we're talking about code with some privilege to see some stacks,
why not reify such privilege in a getStack function importable from
some @privileged module? If you don't reify this distinction, then
you're suggesting above that an access be dependent on the module from
which the access is directly made. What if the access is made
indirectly through some intermediary? Does it then fail, even though
all other accesses can be delegated to the same intermediary? If the
access is simply a property access,
function intermediary(base, name) { return base[name]; }
defined in some other module.
This doesn't sound like something that could be reasonably
standardized into ECMAScript in the near future, and, without all
those pieces in place, it doesn't seem like ECMAScript should just
disallow the ability to get stack traces.
In this thread, we've already considered APIs other than .stack.
Given anything else, why is getStack(err) is any worse than
introducing a novel property name?
Regarding near future, any such proposal -- whether .stack,
getStack, or whatever -- has already missed the boat for ES6. getStack
certainly could be considered in an ES7 timeframe.
Brendan brought up SES - I know little about it, but for its sake I
hope this critical use case is taken into account.
Yes. The code I link to above dates from February.
On Mon, Jun 11, 2012 at 6:17 PM, Brendan Eich bren...@mozilla.org wrote:
I thought so too, but Charles is arguing both (a) no worse than today (not
better than today); (b) useful for people who prefer
non-strict code and a more useful stack-tracing API in the core language.
Just to clarify, I prefer *some* of the ideas behind use strict and
in fact we built a subset of use strict into our in-house tools long
before JSLint existed.
But if it's going to impose a security boundary between my own methods
and reduce the utility of stack traces which are sometimes the only
thing you have to go on.. no thank you. That seems to me to conflate
useful error checking and security; there is overlap, but not 100%
overlap by any means.
How do getStack and @privileged reduce the utility of stack traces?
Regarding access to arguments, depending on how much privilege
@privileged should give (see questions at end of my previous email),
it is conceivable that it should give access to strict arguments as
well. Or that there be an @turbo_privileged that grants this
additional level of access. Until we have some experience using the
module system on both browser and server, these issues are hard to
think about.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
||= is much needed?
Would something like : obj[prop] ||= NewProp be useful? -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On 12 June 2012 01:36, Charles Kendrick char...@isomorphic.com wrote: Your point about not violating use strict or elaborating too much is good, but I want to push back on one thing: local vars may be a bridge too far, especially with optimizing JITs, block-scoped let bindings, etc. Making arguments available is easier. I definitely recognize that making local vars available is different-in-kind from making function arguments available. However I would ideally like to see it mentioned in the spec with recommended but not required wording. I would also push back very hard on this. Besides semantic issues, it would screw compilers, because (among other things) it requires extending liveness of all local variables till the end of their scope (or at least till after its last impure operation). The effect on performance would be significant, I'm sure. Recommended but not required gives you the worst of both worlds: the user cannot rely on the feature, and the implementer is not relieved from the pressure to eventually implement it anyway. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Map#get needs a default value param?
Would it be useful to have something like sum[value] = sum.get(value, 0) + 1 -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Le 12/06/2012 15:27, Hemanth H.M a écrit : Would something like : |obj[prop] ||= NewProp| be useful? ahah, I asked the same question very recently [1]. Answer by Brendan Eich [2]. I definitely agree that default arguments are a decent alternative. I can't recall examples where it wouldn't be enough. Do you have use cases where you would use ||= and default argument values couldn't be used? David [1] https://twitter.com/DavidBruant/status/210654806732324864 [2] https://twitter.com/BrendanEich/status/210750515808706561 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map#get needs a default value param?
Le 12/06/2012 16:19, Hemanth H.M a écrit : Would it be useful to have something like sum[value] = sum.get(value, 0) + 1 You can always do sum[value] = (sum.get(value) || 0) + 1; I think it's simple enough to justify not having an additional (and potentially confusing) argument, but I'm open to debate. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
The big question is whether Function#length should represent minimum or the maximum amount of arguments. That means that a rest parameter could have zero elements, and optional parameters could fall back to their default value. The minimum approach wouldn't count them, the maximum would expect the most and return positive infinity as soon as the rest parameter is available. Both approaches have their right to exist. With the maximum approach, the length property could even become a setter: By setting it, the values always default to the defined value, and rest parameters have a maximum length. It would be nice to get both getters. (Brendan, I'm sorry for sending you this message twice.) 2012/6/11 Brendan Eich bren...@mozilla.org Irakli Gozalishvili wrote: Sorry for not being clear about this. Here is a simplified example of the implementation: https://gist.github.com/**2911817 https://gist.github.com/2911817 Also this is just a single particular example, but I expect there to be more. I think what I'm really asking for is a way to know if …rest is being used. Your code doesn't work on a function that uses arguments the old fashioned way, though. Yes, you can make ...rest affect .length and make a dispatcher that counts on that, but it's a just-so story and a hard case. Hard cases make bad law. If it really matters, we can provide better reflection facilities, but I'm pretty sure it doesn't occur enough to justify doing so now. So use the toString hack if you must and let's see if this use-case becomes hot. Also IMO arrow functions should not have `arguments` at all. That's already in the proposal: http://wiki.ecmascript.org/**doku.php?id=harmony:arrow_**function_syntaxhttp://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax The /Identifier/ primary expression |arguments| may not be used in an arrow function’s body (whether expression or block form). /be Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ On Monday, 2012-06-11 at 11:04 , Allen Wirfs-Brock wrote: On Jun 11, 2012, at 10:56 AM, Irakli Gozalishvili wrote: I don't think any library should ever rely on f.length. That's a wrong attitude, there always will be legitimate uses of any feature, otherwise such features are just harmful IMO should be deprecated / removed. Let me try again. We don't understand your use case. You didn't show us the definition of your dispatch function so we have to guess. Even so, It is hard to imagine a legitimate use with dynamically provided functions, particularly as the length values assigned to the existing built-ins don't follow strict rules. At the very least you need to help us understand why your use case is both reasonable and valid. Allen __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Rest parameter syntax
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Use-case: Most SQL libraries for node support passing query arguments to
the query function (so SQL injections are avoided). The usual syntax
is db.run(SELECT
* FROM t WHERE foo=? AND cbar=?, bar, cfoo, function(err, row){…});
The number of arguments passed after the query depends on the number of
question marks inside the query. It would be nice when an implementation
could simply write db.run = function(query, ...params, cb){…} and avoid
using the arguments object or Array#poping the last element of params.
This change would require two additions: Every Identifier past rest can't
be another rest parameter or have a default value specified.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Tue, Jun 12, 2012 at 10:33 AM, David Bruant bruan...@gmail.com wrote: Le 12/06/2012 15:27, Hemanth H.M a écrit : Would something like : obj[prop] ||= NewProp be useful? There is currently a strawman proposal for the Default Operator, which can be found here: http://wiki.ecmascript.org/doku.php?id=strawman:default_operator Rick ahah, I asked the same question very recently [1]. Answer by Brendan Eich [2]. I definitely agree that default arguments are a decent alternative. I can't recall examples where it wouldn't be enough. Do you have use cases where you would use ||= and default argument values couldn't be used? David [1] https://twitter.com/DavidBruant/status/210654806732324864 [2] https://twitter.com/BrendanEich/status/210750515808706561 ___ 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: Rest parameter syntax
On Tue, Jun 12, 2012 at 10:38 AM, Felix Böhm esdisc...@feedic.com wrote:
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Consider:
function foo( a, b, ...others, c ) {
return [ a, b, others, c ];
}
foo( 1, 2, 3, 4, 5, 6, 7, 8, 9 );
a b others
[ 1, 2, [ 3, 4, 5, 6, 7, 8, 9 ] ]
How do you resolve where to stop claiming arguments as items in the rest
param others?
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Default operator strawman - ||| rather than ??
In the current default operator strawman[1], the operator is ??, e.g.: a = b ?? 5; is shorthand for a = b !== undefined ? b : 5; Would it be possible to use ||| instead? E.g.: a = b ||| 5; I ask because I was planning (prior to knowing about this strawman!) to suggest that, along with a different form of ?? (or ???) which introduces a new ternary operator: a = b ?? 5 : 6; ...which would be a shorthand form of a = b !== undefined ? 5 : 6; [1] http://wiki.ecmascript.org/doku.php?id=strawman:default_operator -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On Tue, Jun 12, 2012 at 11:26 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Jun 12, 2012 at 10:38 AM, Felix Böhm esdisc...@feedic.com wrote:
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Consider:
function foo( a, b, ...others, c ) {
return [ a, b, others, c ];
}
foo( 1, 2, 3, 4, 5, 6, 7, 8, 9 );
a b others
[ 1, 2, [ 3, 4, 5, 6, 7, 8, 9 ] ]
How do you resolve where to stop claiming arguments as items in the rest
param others?
Well, I mean, technically speaking its no different than a very simple
regex.
/(.)(.)(.*)(.)/.exec(123456789);
[123456789, 1, 2, 345678, 9]
/(.)(.)(.*)(.)/.exec(123);
[123, 1, 2, , 3]
From that perspective, it seems pretty deterministic and easy to explain.
There's probably a reason I'm not thinking of, though.
- Russ
Rick
___
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: Rest parameter syntax
Rick Waldron wrote:
On Tue, Jun 12, 2012 at 10:38 AM, Felix Böhm esdisc...@feedic.com
mailto:esdisc...@feedic.com wrote:
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Consider:
function foo( a, b, ...others, c ) {
return [ a, b, others, c ];
}
foo( 1, 2, 3, 4, 5, 6, 7, 8, 9 );
a b others
[ 1, 2, [ 3, 4, 5, 6, 7, 8, 9 ] ]
How do you resolve where to stop claiming arguments as items in the rest
param others?
[ 1, 2, [ 3, 4, 5, 6, 7, 8 ] ]
As I understand Felix's idea, it's that the parameters after ...rest eat
up the last ones. Using last (or last few) params is the often used (not
that I like it) pattern - node.js is full of it since callback is always
last.
But I understand there are problems. First, what with optional params
after ...rest. And the second, how to parse it when foo(1, 2) called?
Rick
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
Felix Böhm wrote:
Per definition, rest parameters always need to be at the end of a
FormalParameterList. I was wondering if this limitation could be liftet.
Use-case: Most SQL libraries for node support passing query arguments to
the query function (so SQL injections are avoided). The usual syntax is
db.run(SELECT * FROM t WHERE foo=? AND cbar=?, bar, cfoo,
function(err, row){…});
The number of arguments passed after the query depends on the number of
question marks inside the query. It would be nice when an implementation
could simply write db.run = function(query, ...params, cb){…} and avoid
using the arguments object or Array#poping the last element of params.
BTW, isn't this possible with comprehensions in parameter list:
db.run = function (query, ...[...params, cb]) { /* body */ }
If yes, problem solved.
This change would require two additions: Every Identifier past rest
can't be another rest parameter or have a default value specified.
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On 12 June 2012 16:42, Herby Vojčík he...@mailbox.sk wrote:
But I understand there are problems. First, what with optional params
after ...rest. And the second, how to parse it when foo(1, 2) called?
I would think with
function foo(a, b, ...others, c) {
}
then given
foo(1, 2);
...within foo a is 1, b is 2, others is empty, and c is undefined. E.g.,
args prior to the restargs get priority over args after rest args. This is
consistent with
foo(1);
...where within foo a is 1, b is undefined, others is empty, and c is
undefined.
It does seem as though it can be deterministic, and pretty easy to explain.
Which isn't necessarily an endorsement, just identifying that this
particular issue doesn't immediately seem like a roadblock.
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map#get needs a default value param?
On Tue, Jun 12, 2012 at 7:36 AM, David Bruant bruan...@gmail.com wrote: Le 12/06/2012 16:19, Hemanth H.M a écrit : Would it be useful to have something like sum[value] = sum.get(value, 0) + 1 You can always do sum[value] = (sum.get(value) || 0) + 1; I think it's simple enough to justify not having an additional (and potentially confusing) argument, but I'm open to debate. The default argument in python's Dict.get doesn't seem confusing, and I've used it plenty. (I've also used the more specialized Dict variants that obviate it - Counter and DefaultDict.) ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
T.J. Crowder wrote:
On 12 June 2012 16:42, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
But I understand there are problems. First, what with optional
params after ...rest. And the second, how to parse it when foo(1, 2)
called?
I would think with
function foo(a, b, ...others, c) {
}
then given
foo(1, 2);
...within foo a is 1, b is 2, others is empty, and c is undefined. E.g.,
args prior to the restargs get priority over args after rest args. This
is consistent with
foo(1);
...where within foo a is 1, b is undefined, others is empty, and c is
undefined.
It does seem as though it can be deterministic, and pretty easy to
explain. Which isn't necessarily an endorsement, just identifying that
function foo (a, b, ...rest, c, d) { ... }
foo(1, 2, 3)
What here?
Yes, [1, 2, [], 3, undefined] is probably the most logical one. But then
d is not the last one (yes, it is only last one when there is at least
four of them).
this particular issue doesn't immediately seem like a roadblock.
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map#get needs a default value param?
Le 12/06/2012 18:02, Tab Atkins Jr. a écrit : On Tue, Jun 12, 2012 at 7:36 AM, David Bruantbruan...@gmail.com wrote: Le 12/06/2012 16:19, Hemanth H.M a écrit : Would it be useful to have something like sum[value] = sum.get(value, 0) + 1 You can always do sum[value] = (sum.get(value) || 0) + 1; I think it's simple enough to justify not having an additional (and potentially confusing) argument, but I'm open to debate. The default argument in python's Dict.get doesn't seem confusing, and I've used it plenty. (I've also used the more specialized Dict variants that obviate it - Counter and DefaultDict.) sum.get(value) || 0 leaves no ambiguity (assuming you know JavaScript and falsy values) as to when the value is 0, while for sum.get(value, 0), the implicit part is in the semantics of the function for which you need to look at the spec, that's what I find more confusing. YMMV. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On 12 June 2012 17:03, Herby Vojčík he...@mailbox.sk wrote:
function foo (a, b, ...rest, c, d) { ... }
foo(1, 2, 3)
What here?
Yes, [1, 2, [], 3, undefined] is probably the most logical one. But then d
is not the last one (yes, it is only last one when there is at least four
of them).
Yeah, I was regretting not addressing that case. :-)
I'd say your interpretation (1, 2, [], 3, undefined) would be the best
answer, and easiest to explain. There's a temptation to suggest that you
could reverse c and d (1, 2, [], undefined, 3), but that way surely lies
madness...
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Get]] and GetValue can return Reference Type
On Jun 11, 2012, at 11:03 PM, Yusuke Suzuki wrote:
This issue is derived from Esprima issue 81
http://code.google.com/p/esprima/issues/detail?id=81
Hello everyone,
According to the ECMA262 5.1th, [[Call]] of host object may return Reference
Type.
So, all values using raw [[Call]] result may be Reference Type.
For example, [[Get]] may return Reference Type if getter is a host object
that [[Call]] returns Reference Type.
http://ecma-international.org/ecma-262/5.1/#sec-8.12.3
As the result, GetValue may return Reference Type because that use result
value of [[Get]]
http://ecma-international.org/ecma-262/5.1/#sec-8.7.1
And, for example, if we define getter of object, getter function is host
object that [[Call]] return Reference Type,
(10, obj.getter)
returns Reference type, so,
(10, obj.getter) = 10;
is valid because GetValue is performed, but GetValue result is also Reference
Type.
In the ECMA262 5.1th, GetValue is assumed that doesn't return Reference Type,
for exmaple,
var obj = {
get v() {
// this v function is host object and returns Reference;
// we can define this v using host object and defineProperty
return Reference;
}
};
And,
typeof obj.v
Then, typeof should treat Reference Type also, but in 11.4.3, Reference Type
is not considered.
http://ecma-international.org/ecma-262/5.1/#sec-11.4.3
I think this is a bug of spec and GetValue and [[Get]] should not return
Reference type, is it right?
To fix this, I think following 3 way are good.
perform GetValue on [[Call]] result in the spec
re-define [[Get]] and GetValue can return Reference Type. This needs to
re-define all the spec part using [[Get]], GetValue and others
remove feature that [[Call]] can return Reference Type
Because all modern engines don't consider that [[Call]] result is Reference
and this feature makes big performance-regression, personally I think 3 is
better.
Well, if your implementation doesn't provide a way for host functions to
return Reference values then you don't have to worry about it...
But, I agree that this seems to be an issue and that it was introduced into
the spec. when accessor properties were added.
I also think the preferable way to fix it would be to remove the [[Call]]
returning Reference feature. The last time we discussed this, I believe there
was some effort made to keep HTML5 from enshrining legacy IE behavior that
required this. Does anybody remember? If it is only legacy IE that depends
upon this feature then I'd think we could drop it. Any implementation that
wants [[Call]] returning References could still provide them as a non-standard
extension.
Allen
Regards,
Yusuke Suzuki
___
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: ||= is much needed?
Kool, well was looking into use caseswell my first frustration was [1] I'm new to this, how does one write proposals? Is it a wiki? [1] https://twitter.com/GNUmanth/status/208555914733682690 On Tue, Jun 12, 2012 at 8:36 PM, Rick Waldron waldron.r...@gmail.comwrote: http://wiki.ecmascript.org/doku.php?id=strawman:default_operator -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On Jun 12, 2012, at 8:49 AM, Herby Vojčík wrote:
...
BTW, isn't this possible with comprehensions in parameter list:
db.run = function (query, ...[...params, cb]) { /* body */ }
If yes, problem solved.
Current draft requires an identifier after ... in a rest position
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map#get needs a default value param?
True! It will be confusing; || is uber kool :) On Tue, Jun 12, 2012 at 9:37 PM, David Bruant bruan...@gmail.com wrote: Le 12/06/2012 18:02, Tab Atkins Jr. a écrit : On Tue, Jun 12, 2012 at 7:36 AM, David Bruantbruan...@gmail.com wrote: Le 12/06/2012 16:19, Hemanth H.M a écrit : Would it be useful to have something like sum[value] = sum.get(value, 0) + 1 You can always do sum[value] = (sum.get(value) || 0) + 1; I think it's simple enough to justify not having an additional (and potentially confusing) argument, but I'm open to debate. The default argument in python's Dict.get doesn't seem confusing, and I've used it plenty. (I've also used the more specialized Dict variants that obviate it - Counter and DefaultDict.) sum.get(value) || 0 leaves no ambiguity (assuming you know JavaScript and falsy values) as to when the value is 0, while for sum.get(value, 0), the implicit part is in the semantics of the function for which you need to look at the spec, that's what I find more confusing. YMMV. David -- *'I am what I am because of who we all are'* h3manth.com http://www.h3manth.com *-- Hemanth HM * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
We have had several previous discussions about such possibilities on this list.
Bottom line, is that destructuring (including formal parameters) could be moved
towards something that is more like generalized pattern matching. However, it
isn't clear that the additional specification, implementation, and usage
complexity is justified at this time. For ES6 we have the most important use
cases covered. If experience with it suggests that some generalizations would
add real value we can consider them for future editions.
Allen
On Jun 12, 2012, at 9:10 AM, T.J. Crowder wrote:
On 12 June 2012 17:03, Herby Vojčík he...@mailbox.sk wrote:
function foo (a, b, ...rest, c, d) { ... }
foo(1, 2, 3)
What here?
Yes, [1, 2, [], 3, undefined] is probably the most logical one. But then d is
not the last one (yes, it is only last one when there is at least four of
them).
Yeah, I was regretting not addressing that case. :-)
I'd say your interpretation (1, 2, [], 3, undefined) would be the best
answer, and easiest to explain. There's a temptation to suggest that you
could reverse c and d (1, 2, [], undefined, 3), but that way surely lies
madness...
-- T.J.
___
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: Rest parameter syntax
As written before:
function foo(a, b, ...others, c){ … }
behaves the same as
function foo(a, b, ...others){
var c = others.pop();
}
When the number of parameters following the rest parameter is greater or
equal the number of passed arguments, the rest parameter is an empty array
and the parameters get assigned in order until there are no more arguments.
Unassigned parameters default to undefined.
When the number of arguments is greater than the number of parameters
following the rest parameter, then the first(argument-number -
parameter-number) arguments are passed as the rest parameter.
2012/6/12 Herby Vojčík he...@mailbox.sk
T.J. Crowder wrote:
On 12 June 2012 16:42, Herby Vojčík he...@mailbox.sk
mailto:he...@mailbox.sk wrote:
But I understand there are problems. First, what with optional
params after ...rest. And the second, how to parse it when foo(1, 2)
called?
I would think with
function foo(a, b, ...others, c) {
}
then given
foo(1, 2);
...within foo a is 1, b is 2, others is empty, and c is undefined. E.g.,
args prior to the restargs get priority over args after rest args. This
is consistent with
foo(1);
...where within foo a is 1, b is undefined, others is empty, and c is
undefined.
It does seem as though it can be deterministic, and pretty easy to
explain. Which isn't necessarily an endorsement, just identifying that
function foo (a, b, ...rest, c, d) { ... }
foo(1, 2, 3)
What here?
Yes, [1, 2, [], 3, undefined] is probably the most logical one. But then d
is not the last one (yes, it is only last one when there is at least four
of them).
this particular issue doesn't immediately seem like a roadblock.
-- T.J.
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
On Mon, Jun 11, 2012 at 3:50 PM, Brendan Eich bren...@mozilla.org wrote: Irakli Gozalishvili wrote: Sorry for not being clear about this. Here is a simplified example of the implementation: https://gist.github.com/**2911817 https://gist.github.com/2911817 Also this is just a single particular example, but I expect there to be more. I think what I'm really asking for is a way to know if …rest is being used. Your code doesn't work on a function that uses arguments the old fashioned way, though. Yes, you can make ...rest affect .length and make a dispatcher that counts on that, but it's a just-so story and a hard case. Hard cases make bad law. If it really matters, we can provide better reflection facilities, but I'm pretty sure it doesn't occur enough to justify doing so now. So use the toString hack if you must and let's see if this use-case becomes hot. I think this is a pretty creative snippet of code, but ultimately unreliable for the reasons mentioned. It does bring up something else, though, that I've avoided mentioning so far, which is pattern matching. I haven't mentioned it because there is clearly a strawmanhttp://wiki.ecmascript.org/doku.php?id=strawman:pattern_matchingfor it, and that never made it to harmony, but in light of this thread I wanted to reiterate how useful it would be. It would not really help function.length, but would address the real underlying problem that the arity dispatcher is trying to tackle. In a language without overloading, the ability to do pattern matching would be an excellent solution to a very common problem. We already have destructuring, it seems like such a small jump to pattern matching. Hard to tell from looking at the strawman why that never made it. If its a matter or feature bloat, I would rate that higher than some other things like default args or array comprehensions. - Russ - Russ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On 12 June 2012 17:21, Felix Böhm esdisc...@feedic.com wrote:
As written before:
function foo(a, b, ...others, c){ … }
behaves the same as
function foo(a, b, ...others){
var c = others.pop();
}
Sadly, it's not as simple to emulate
function foo(a, b, ...others, c, d) {
}
...using pop. But obviously it can be done one way or another.
When the number of parameters following the rest parameter is greater or
equal the number of passed arguments, the rest parameter is an empty array
and the parameters get assigned in order until there are no more arguments.
Unassigned parameters default to undefined.
When the number of arguments is greater than the number of parameters
following the rest parameter, then the first(argument-number -
parameter-number) arguments are passed as the rest parameter.
Yes, the rule doesn't seem particularly complicated.
I've definitely seen (and very occasionally used) this sort of thing in the
real world, though not nearly to Node's extent. The beginning and end of
the args list are the only fixed points.
On 12 June 2012 17:21, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
For ES6 we have the most important use cases covered. If experience with
it suggests that some generalizations would add real value we can consider
them for future editions.
Very true, no reason it couldn't be loosened up in ES7 or whatever. And
yet, if not yet implemented in its current form (I have no idea what the
extent of implementation is), the complexity increment does not seem large.
As Felix points out, the algorithm isn't exactly complicated.
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
Mark S. Miller wrote: I'm not yet arguing that or the opposite, rather, I'm confused about what non-strict-only means in this context. Actual stacks consist of a mixture of strict and non-strict activations. This isn't so in personal projects or even all-homegrown products or shared projects that eschew use strict, as Charles wrote. How would the proposed API deal with that? Eliding strict frames' arguments, Charles wrote. I objected that this makes any such stack trace API hard to use in the large, compared to an information-leaking string-valued .stack approach. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
T.J. Crowder wrote: Very true, no reason it couldn't be loosened up in ES7 or whatever. Right, this is a virtue. And yet, if not yet implemented in its current form (I have no idea what the extent of implementation is), the complexity increment does not seem large. Here you went down the bad path. It was not the last cookie I ate that made me fat. Every little wafer-thin (cf. MPTMoL) increment hurts. Every single one. As Felix points out, the algorithm isn't exactly complicated. More bad-path words, ignore the little horned red guy on your shoulder. This is a marginal use-case, you said so yourself. It can take the long way 'round. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
snip But I understand there are problems. First, what with optional params after ...rest. And the second, how to parse it when foo(1, 2) called? There was a lengthy thread about this, here: https://mail.mozilla.org/pipermail/es-discuss/2012-April/022256.html Rick ps. This is an alternate, nested thread view: http://old.nabble.com/Fwd%3A-undefined-being-treated-as-a-missing-optional-argument-tt33672515.html Rick Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
Russell Leggett wrote:
It does bring up something else, though, that I've avoided mentioning
so far, which is pattern matching. I haven't mentioned it because
there is clearly a strawman
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching for
it, and that never made it to harmony, but in light of this thread I
wanted to reiterate how useful it would be. It would not really help
function.length, but would address the real underlying problem that
the arity dispatcher is trying to tackle. In a language without
overloading, the ability to do pattern matching would be an excellent
solution to a very common problem. We already have destructuring, it
seems like such a small jump to pattern matching.
You are preacher, dherman and I are choir. Maybe patterns will make ES7.
We shall try again.
Hard to tell from looking at the strawman why that never made it. If
its a matter or feature bloat, I would rate that higher than some
other things like default args or array comprehensions.
See March 2011 TC39 meeting notes, second day.
Quotes below. Note some fine specimens of TC39's future-proofing
fetishization on parade. I will say no more, as I think Dave agrees
patterns were not fully baked.
The way to get refutable matching into ES7 is to work now to address all
the valid worries, and say why the other worries are false.
/be
[From https://mail.mozilla.org/pipermail/es-discuss/2011-March/013403.html]
Refutable matching and switch extensions:
Multiple objections to syntax chosen for pattern-matching switch:
colon vs. no colon after default clause, need for blocks, etc.
Refutable matching doesn't retrofit into imperative switch syntax
well.
Waldemar: Refutable matching is half-baked at this point, with too
many syntactic and semantic problems. Not clear it's worth its added
complexity.
The refutable matching wiki has the following consequences on
irrefutable matching:
Pattern [x,y]:
Matched to [3,4], produces x=3, y=4.
Matched to [3,4,5], produces x=3, y=4.
Matched to [3], produces x=undefined, y=undefined. (wiki spec bug.)
Pattern [..., x, y]:
Matched to [3,4], produces x=3, y=4.
Matched to [3], looks up negative array indices. (wiki spec bug.)
Pattern [x,y] behaves like [x,y,...] for refutable matching. (wiki spec bug.)
Can't match on zero-length arrays. (wiki spec bug?)
Lucas: Feature value should overcome complexity costs.
Waldemar: if guards introduce unknown syntactic and semantic complexity
Waldemar: where can you use refutable matching outside of switch/match
statements and perhaps catch guards? switch/match statements are too
heavyweight and differ too much from irrefutable matching assignment;
catching doesn't really need destructuring but benefits from
conditions. The typical usage (as in Perl) is to use them in if
statements: if (pattern =~ expr) {we have matched!}
catch({z,w} if z w): OK, but then you can't get to the entire
exception object from the catch clause.
catch(z if z instanceof T): Useful
Waldemar: Refutable matching should integrate trademarking to be compelling.
Concern about backing ourselves into a corner by implementing
irrefutable pattern matching in catch guards that will later preclude
refutable matching. Brendan's example: catch({x, y}) would succeed
on {x:3} now but fail later if we change to refutable pattern
matching.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map#get needs a default value param?
On Tue, Jun 12, 2012 at 9:07 AM, David Bruant bruan...@gmail.com wrote: Le 12/06/2012 18:02, Tab Atkins Jr. a écrit : On Tue, Jun 12, 2012 at 7:36 AM, David Bruantbruan...@gmail.com wrote: Le 12/06/2012 16:19, Hemanth H.M a écrit : Would it be useful to have something like sum[value] = sum.get(value, 0) + 1 You can always do sum[value] = (sum.get(value) || 0) + 1; I think it's simple enough to justify not having an additional (and potentially confusing) argument, but I'm open to debate. The default argument in python's Dict.get doesn't seem confusing, and I've used it plenty. (I've also used the more specialized Dict variants that obviate it - Counter and DefaultDict.) sum.get(value) || 0 leaves no ambiguity (assuming you know JavaScript and falsy values) as to when the value is 0, while for sum.get(value, 0), the implicit part is in the semantics of the function for which you need to look at the spec, that's what I find more confusing. YMMV. The problem is that the simple expression works for this example, because we know that if the value is set, it will be set to a non-zero number. Thus, all set values are truthy, and we can rely on undefined being the only falsey value in the map. In the more general case where the map might legitimately be holding 0, false, or null, this assumption breaks and you have to go with the wordier variant: var temp = sum.get(value); sum.set(value, temp === undefined ? 1 : temp + 1); Of course, the default operator would return us to your simpler expression: sum.set(value, (sum.get(value) ?? 0) + 1; This isn't too bad, and we can always wait for the language to expand with subtypes of Map that handle this behavior better (or use a library), like the aforementioned Counter and DefaultDict of Python. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error stack
On Tue, Jun 12, 2012 at 5:19 AM, Mark S. Miller erig...@google.com wrote: On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick char...@isomorphic.com wrote: The only way I can see this working is if there is a way for a given piece of code to trap an error and ask some kind of (elevated privilege) logging system to provide diagnostic information that a (privileged) end user can see. I'm not sure what you mean by trap to an error, My actual words were to trap an error so that probably explains the confusion :) but the rest of your description seems close to how SES's console.log, console.warn, etc work. They are endowed with access to the privileged getStack function and use it to display stack traces on the console's output. See http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#28 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#157 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js#116 Yes, this is the pattern I had in mind. This also means there would be no need to worry about exposing too much information in a stack trace. It also seems like, in addition to this, you should be able to get to stack information programmatically so long as you stay within your module or modules that have the same privilege. If we're talking about code with some privilege to see some stacks, why not reify such privilege in a getStack function importable from some @privileged module? I don't have an objection to this being treated as an import. This doesn't sound like something that could be reasonably standardized into ECMAScript in the near future, and, without all those pieces in place, it doesn't seem like ECMAScript should just disallow the ability to get stack traces. In this thread, we've already considered APIs other than .stack. Given anything else, why is getStack(err) is any worse than introducing a novel property name? There's no problem with the API being changed to a getter method as opposed to error.stack / error.stackFrames. It would be a problem for access to a stack trace to require @import or other features that are not yet present in all mainstream browsers. If browser implementers cannot add this feature to engines which are basically only ES4/5, it's not going to be usable for mainstream code until 2019 or something - in reality, non-standard APIs will continue to be implemented and used. Regarding near future, any such proposal -- whether .stack, getStack, or whatever -- has already missed the boat for ES6. getStack certainly could be considered in an ES7 timeframe. Fortunately, these milestones have little to do with when features appear in browsers. And this is one of those features where it's valuable the moment it appears in just one browser. All we really need is clear consensus, so as to influence browser vendors' existing efforts in this area. Just to clarify, I prefer *some* of the ideas behind use strict and in fact we built a subset of use strict into our in-house tools long before JSLint existed. But if it's going to impose a security boundary between my own methods and reduce the utility of stack traces which are sometimes the only thing you have to go on.. no thank you. That seems to me to conflate useful error checking and security; there is overlap, but not 100% overlap by any means. How do getStack and @privileged reduce the utility of stack traces? They don't. The above discussion is about use strict and is not about SES. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On 12 June 2012 18:00, Brendan Eich bren...@mozilla.org wrote: T.J. Crowder wrote: And yet, if not yet implemented in its current form (I have no idea what the extent of implementation is), the complexity increment does not seem large. Here you went down the bad path. It was not the last cookie I ate that made me fat. Every little wafer-thin (cf. MPTMoL) increment hurts. Every single one. As Felix points out, the algorithm isn't exactly complicated. More bad-path words, ignore the little horned red guy on your shoulder. This sort of argument can almost _always_ be applied. Again, not saying I really endorse the embedded varargs, but I don't think this is a persuasive argument against _on its own_. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
T.J. Crowder wrote: On 12 June 2012 18:00, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: T.J. Crowder wrote: And yet, if not yet implemented in its current form (I have no idea what the extent of implementation is), the complexity increment does not seem large. Here you went down the bad path. It was not the last cookie I ate that made me fat. Every little wafer-thin (cf. MPTMoL) increment hurts. Every single one. As Felix points out, the algorithm isn't exactly complicated. More bad-path words, ignore the little horned red guy on your shoulder. This sort of argument can almost _always_ be applied. Again, not saying I really endorse the embedded varargs, but I don't think this is a persuasive argument against _on its own_. You are correct! The context matters. In that context, your argument that the complexity increment does not seem large is also not a persuasive argument *for* adding that increment, and I call it worse: a sign (in context of rest as drafted for ES6) that you're going too far. Red guy still on your shoulder :-P. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Tue, Jun 12, 2012 at 11:45 AM, Ryan Florence rpflore...@gmail.comwrote:
I use ||= very regularly in ruby and coffeescript, both of which have
default arguments.
I definitely agree that default arguments are a decent alternative. I
can't recall examples where it wouldn't be enough. Do you have use cases
where you would use ||= and default argument values couldn't be used?
Its super handy for caching and late/dynamic initialization of object
properties.
var events = {
_callbacks: {},
on: function (topic, callback) {
(this._callbacks[topic] ||= []).push(callback);
...
},
...
};
It's also useful for settings object defaults, especially for expensive
settings that you don't want to calculate in some `defaults` object that is
merged into the settings.
function ajaxWithError (settings) {
settings.method ||= 'POST';
settings.elementPosition ||= this._getElementPositions();
settings.somethingWithInitialization ||= (function(){
var thing = new Thing();
thing.foo = settings.foo;
return thing;
})();
...
};
The ||= (function(){})() should remind any rubyist of `||= begin ... end`
which is beloved by many.
So yeah, I think its really useful outside of default arguments.
- Ryan Florence
Forgive the dogpiling, but these are really excellent real-world use cases
that represent massive pain points in modern JavaScript programming. Thanks
for writing these up Ryan, I've added them to strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On 12 June 2012 18:14, Brendan Eich bren...@mozilla.org wrote: Red guy still on your shoulder :-P. I think you're seeing things. ;-) But seriously, I don't really have a horse in this race (at all, I was just exploring the concept -- seems that's already been done), happy to leave it at that. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map#get needs a default value param?
Tab Atkins Jr. wrote: This isn't too bad, and we can always wait for the language to expand with subtypes of Map that handle this behavior better (or use a library), like the aforementioned Counter and DefaultDict of Python. Previously: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019723.html et seq. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
+1
I desperately want this in the language.
AJ ONeal
On Tue, Jun 12, 2012 at 11:14 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Jun 12, 2012 at 11:45 AM, Ryan Florence rpflore...@gmail.comwrote:
I use ||= very regularly in ruby and coffeescript, both of which have
default arguments.
I definitely agree that default arguments are a decent alternative. I
can't recall examples where it wouldn't be enough. Do you have use cases
where you would use ||= and default argument values couldn't be used?
Its super handy for caching and late/dynamic initialization of object
properties.
var events = {
_callbacks: {},
on: function (topic, callback) {
(this._callbacks[topic] ||= []).push(callback);
...
},
...
};
It's also useful for settings object defaults, especially for expensive
settings that you don't want to calculate in some `defaults` object that is
merged into the settings.
function ajaxWithError (settings) {
settings.method ||= 'POST';
settings.elementPosition ||= this._getElementPositions();
settings.somethingWithInitialization ||= (function(){
var thing = new Thing();
thing.foo = settings.foo;
return thing;
})();
...
};
The ||= (function(){})() should remind any rubyist of `||= begin ... end`
which is beloved by many.
So yeah, I think its really useful outside of default arguments.
- Ryan Florence
Forgive the dogpiling, but these are really excellent real-world use cases
that represent massive pain points in modern JavaScript programming. Thanks
for writing these up Ryan, I've added them to strawman:
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator
Rick
___
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: ||= is much needed?
Rick Waldron wrote:
On Tue, Jun 12, 2012 at 11:45 AM, Ryan Florence rpflore...@gmail.com
mailto:rpflore...@gmail.com wrote:
I use ||= very regularly in ruby and coffeescript, both of which
have default arguments.
I don't see Ryan's mail.
First, as we've discussed in the past, ||= in Ruby is not what we've
proposed. In JS, assignment operators expand like so
A op= B; ~~ A = A op B;
with of course a temporary to hold the base of A (which must evaluate to
a Reference) so side effects are not duplicated.
In Ruby IIRC, A ||= B is A = B unless A (hope I have this right).
This matters if A is an accessor. Do we always set A, even to its
current value if truthy?
I definitely agree that default arguments are a decent
alternative. I can't recall examples where it wouldn't be
enough. Do you have use cases where you would use ||= and
default argument values couldn't be used?
Its super handy for caching and late/dynamic initialization of
object properties.
var events = {
_callbacks: {},
on: function (topic, callback) {
(this._callbacks[topic] ||= []).push(callback);
...
},
...
};
This is handy, and also idiomatic but to multiple languages.
It's worth considering, but we need to wrestle the semantics to the
ground. If the left-hand side's value is truthy, I argue there should be
no useless assignment of that value to the left-hand side.
IOW I favor Ruby semantics. This breaks from JS's C-inspired assignment
operators, but perhaps we can live with it.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
This breaks from JS's C-inspired assignment operators, but perhaps we can live with it. FWIW -- I was confused when I first read ||=, I thought it was supposed to be some kind of Boolean-coercing variant on |=. Now I see that it is more like ?= from GNU make. What do you think of GCC's ?: operator? It is basically a special form of the ternary operator, and while not the same as your propsal, it addresses many of the same use cases. (I've been happy with it for a long time). Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Wes Garland wrote: This breaks from JS's C-inspired assignment operators, but perhaps we can live with it. FWIW -- I was confused when I first read ||=, I thought it was supposed to be some kind of Boolean-coercing variant on |=. Now I see that it is more like ?= from GNU make. We could use ?= instead. Good point. This avoids the dual semantics for A op= B split on whether op is || (an existing operator, unlike lone ?). What do you think of GCC's ?: operator? It is basically a special form of the ternary operator, and while not the same as your propsal, it addresses many of the same use cases. That's ok as an alternative to ?? but would you want ?:= as the assignment form? I'd rather lose the colon. Given ?=, people may wish for A ? B instead of A ?? B, but then we have nasty issues with respect to ternary: A ? B ? C : D Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the formal grammar but readers may rebel. It's possible ?? or however we spell it isn't worth adding, while ?= is. The conditional assignment to default or normalize is the prime use-case. Even then, we have lingering debates over falsy vs. null-or-undefined vs. undefined only. CoffeeScript does null-or-undefined, IIRC. /be (I've been happy with it for a long time). Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ 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: ||= is much needed?
Brendan Eich wrote: Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the formal grammar but readers may rebel. Or A ? (B ? C : D), of course. Just say no to lone ? as new operator. I'm warming up to ?= though! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
I like the sound of ?= too. var a; //later on a ?= 15; It goes with all the other operators that are out there too (!=, =, ==, === etc). Tom On 12 Jun 2012, at 19:04, Brendan Eich wrote: Brendan Eich wrote: Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the formal grammar but readers may rebel. Or A ? (B ? C : D), of course. Just say no to lone ? as new operator. I'm warming up to ?= though! /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: ||= is much needed?
On Tue, Jun 12, 2012 at 2:31 PM, Tom Ellis tellis...@gmail.com wrote: I like the sound of ?= too. var a; //later on a ?= 15; It goes with all the other operators that are out there too (!=, =, ==, === etc). +1, useful and intuitive. - Russ Tom On 12 Jun 2012, at 19:04, Brendan Eich wrote: Brendan Eich wrote: Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the formal grammar but readers may rebel. Or A ? (B ? C : D), of course. Just say no to lone ? as new operator. I'm warming up to ?= though! /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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
Another nice place for this syntax would be destructuring: If you want to
get the last elements of an array, you might want to simply use
[...arr, foo, bar] = arr;
I really like that syntax. And in the end, that's what
function(...arr, foo, bar){…}
is doing. The difference to
bar = arr.pop();
foo = arr.pop();
is that foo is preferred when only one value is available. Written in the
JS of today, you'll need to write
if(arr.length 0){
if(arr.length !== 1){
bar = arr.pop();
}
foo = arr.pop();
}
And it'll get more complicated with every added variable.
It's quite interesting that Herby used that syntax with the only feedback
being that he can't use destructuring at that place :D
@Rick: I don't get your point. Of course, undefined should be treated as
any other value, everything else would be confusing. Or what were
you referring to?
As I've already written, parameters after rest can't have default values,
which (partially) fixes the issue of optional parameters.
2012/6/12 T.J. Crowder t...@crowdersoftware.com
On 12 June 2012 18:14, Brendan Eich bren...@mozilla.org wrote:
Red guy still on your shoulder :-P.
I think you're seeing things. ;-) But seriously, I don't really have a
horse in this race (at all, I was just exploring the concept -- seems
that's already been done), happy to leave it at that.
-- T.J.
___
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: ||= is much needed?
Russell Leggett wrote: On Tue, Jun 12, 2012 at 2:31 PM, Tom Ellis tellis...@gmail.com mailto:tellis...@gmail.com wrote: I like the sound of ?= too. var a; //later on a ?= 15; It goes with all the other operators that are out there too (!=, =, ==, === etc). +1, useful and intuitive. And (to be clear) the semantics for LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Let rval = GetValue(rref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, call PutValue(lref, rval). to assign the default value if and only if the left-hand side's current value is undefined. /be - Russ Tom On 12 Jun 2012, at 19:04, Brendan Eich wrote: Brendan Eich wrote: Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the formal grammar but readers may rebel. Or A ? (B ? C : D), of course. Just say no to lone ? as new operator. I'm warming up to ?= though! /be ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org mailto: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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
On Tue, Jun 12, 2012 at 2:56 PM, Felix Böhm esdisc...@feedic.com wrote:
Another nice place for this syntax would be destructuring: If you want to
get the last elements of an array, you might want to simply use
[...arr, foo, bar] = arr;
I really like that syntax. And in the end, that's what
function(...arr, foo, bar){…}
is doing. The difference to
bar = arr.pop();
foo = arr.pop();
is that foo is preferred when only one value is available. Written in the
JS of today, you'll need to write
if(arr.length 0){
if(arr.length !== 1){
bar = arr.pop();
}
foo = arr.pop();
}
And it'll get more complicated with every added variable.
It's quite interesting that Herby used that syntax with the only feedback
being that he can't use destructuring at that place :D
@Rick: I don't get your point. Of course, undefined should be treated as
any other value, everything else would be confusing. Or what were
you referring to?
Revisit...
function foo( a, b, ...others, c ) {
return [ a, b, others, c ];
}
foo( 1, 2, 3, 4, 5, 6, 7, 8, 9 );
It's clear to me that you want any formal params that follow a ...rest to
pop values off the arguments list until the params are satisfied, ie. c = 9.
The context of my question assumed there was a desire to avoid the
complexity and that the discussion had already reached consensus on only
allowing rest params at the end of a formal parameter list.
Rick
As I've already written, parameters after rest can't have default values,
which (partially) fixes the issue of optional parameters.
2012/6/12 T.J. Crowder t...@crowdersoftware.com
On 12 June 2012 18:14, Brendan Eich bren...@mozilla.org wrote:
Red guy still on your shoulder :-P.
I think you're seeing things. ;-) But seriously, I don't really have a
horse in this race (at all, I was just exploring the concept -- seems
that's already been done), happy to leave it at that.
-- T.J.
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Brendan Eich wrote: LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Of course, A should be LeftHandSideExpression and B should be AssignmentExpression. This is pretty simple. We could even grant an exception and get it into ES6, IMHO. But first it needs a strawman and some discussion. Absent fast objections here, I'll co-opt the http://wiki.ecmascript.org/doku.php?id=strawman:default_operator strawman and put it on the agenda. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rest parameter syntax
Rick Waldron wrote: The context of my question assumed there was a desire to avoid the complexity and that the discussion had already reached consensus on only allowing rest params at the end of a formal parameter list. That's the safe play for ES6, which must be prototyped and drafted this year, pretty much limiting new complexity. As noted in the other thread, we're now talking about a pattern language for matching (refutably or irrefutably), which was proposed last year: http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Happy to use es-discuss to work out something richer than ES6 rest-only-at-end. I write this not to nag anyone, just to make my own position clear in case it sounded like I was against the idea of richer patterns than rest and destructuring as currently proposed or drafted. I'm not! Let's discuss. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder t...@crowdersoftware.com wrote: In the current default operator strawman[1], the operator is ??, e.g.: a = b ?? 5; is shorthand for a = b !== undefined ? b : 5; I missed this discussion. What validates the introduction of this syntax over the equally simple and already possible `a = b || 5`? Is the comparison to `undefined` (and why not `==null` as well??) really worth the introduction (and subsequent loss of future usage) of the double question mark? Whatever it's usual name is (double wat?). Would it be possible to use ||| instead? E.g.: a = b ||| 5; If the above is this, absolutely and such a feature, I favor this as well because it resembles the `a = b || 5` expression better. [1] http://wiki.ecmascript.org/doku.php?id=strawman:default_operator (Read that before posting, did not see anything compelling) - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
If the above is this, absolutely and such a feature, I favor this as Wow, something messed up big time. If the above answer is this, absolute and such a feature is seriously considered ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 1:37 PM, Peter van der Zee e...@qfox.nl wrote: On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder t...@crowdersoftware.com wrote: In the current default operator strawman[1], the operator is ??, e.g.: a = b ?? 5; is shorthand for a = b !== undefined ? b : 5; I missed this discussion. What validates the introduction of this syntax over the equally simple and already possible `a = b || 5`? Is the comparison to `undefined` (and why not `==null` as well??) really worth the introduction (and subsequent loss of future usage) of the double question mark? Whatever it's usual name is (double wat?). If b is falsey (0, false, null), it'll use the 5, even though you only intended it to be used when b is undefined. undefined is special-cased here because it's an extremely common value to check against. It's used when an argument isn't supplied, or when you try to pull a non-existent property off of an object. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
On Tue, Jun 12, 2012 at 1:06 PM, Brendan Eich bren...@mozilla.org wrote:
Russell Leggett wrote:
It does bring up something else, though, that I've avoided mentioning so
far, which is pattern matching. I haven't mentioned it because there is
clearly a strawman http://wiki.ecmascript.org/**
doku.php?id=strawman:pattern_**matchinghttp://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching
for it, and that never made it to harmony, but in light of this thread I
wanted to reiterate how useful it would be. It would not really help
function.length, but would address the real underlying problem that the
arity dispatcher is trying to tackle. In a language without overloading,
the ability to do pattern matching would be an excellent solution to a very
common problem. We already have destructuring, it seems like such a small
jump to pattern matching.
You are preacher, dherman and I are choir. Maybe patterns will make ES7.
We shall try again.
Hard to tell from looking at the strawman why that never made it. If its
a matter or feature bloat, I would rate that higher than some other things
like default args or array comprehensions.
See March 2011 TC39 meeting notes, second day.
Quotes below. Note some fine specimens of TC39's future-proofing
fetishization on parade. I will say no more, as I think Dave agrees
patterns were not fully baked.
The way to get refutable matching into ES7 is to work now to address all
the valid worries, and say why the other worries are false.
This thread gave me an interesting idea on how to possibly attack pattern
matching in ES6 with no new syntax, and still leave room for more sugar
later. It actually comes from thinking about the original issue with
function.length and using it for arity-based dispatch. What if we just gave
a better method than length? What if we had something like
function.matches(args)? Where it would return true if all arguments were
bound, and no parameters resulted in an undefined binding.
function add(a,b){
return a + b;
}
add.matches(1,2); // = true
add.matches(1); // = false
add.matches(1,2,3); = false
This still suffers from the same problem as function.length, and when
dealing with simple arity and no destructuring/rest params, would act
exactly the same. However, Irakli's dispatcher utility does lay the
groundwork for something more interesting.
function makePoint(x,y){ return {x:x,y:y}; }
function drawLine({x:x1,y:y1},{x:x2,y:y2}){...}
let p1 = makePoint(1,2), p2 = makePoint(3,4);
drawLine.matches(p1,p2); // = true
drawLine.matches(1,2); // = false
drawLine.matches({x:1}, {y:2}) // = false
//only has to be a structural subset
drawLine.matches({x:1,y:2,z:3}, {x:1, y:2}) // = true
With that simple boolean function, Irakli's dispatcher utility could be
rewritten to loop through the list and check for a match instead of by
arity. It would work correctly for rest parameters, but even more
interesting, would work with all of the destructuring patterns.
let drawLine = dispatcher(
(x1,y1,x2,y2) = ...,
({x:x1,y:y1},{x:x2,y:y2}) = ...
);
Or a more functional replacement for switch
let result = match(value,
({x,y,z}) = 3d
({x,y}) = 2d
(...anything) = not a point
);
Its not as nice as full pattern matching with literals and wildcards, but
it could be pretty clean. If guards were added later, that would be an
obvious fit. If it became a popular pattern, we could pave the cowpath with
some sugar, and add the things that are missing now.
One of the benefits of getting started this way is that it could be shimmed
to just use length.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 10:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: undefined is special-cased here because it's an extremely common value to check against. It's used when an argument isn't supplied, or when you try to pull a non-existent property off of an object. I believe the most common case for an undefined argument is to either provide undefined OR null. I prefer null because it's not a global look up and because it's shorter. So when I _have_ to write a function call with empty parameter I supply null as the argument. Where I'm going with that is to point out that the specific undefined (only) case doesn't feel to be a de facto standard in the js world to validate special syntax for it. And even if it did, please let it take null into account as well. In these cases, who really does `x === undefined` opposed to just `x == null`? - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 1:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jun 12, 2012 at 1:37 PM, Peter van der Zee e...@qfox.nl wrote:
On Tue, Jun 12, 2012 at 5:29 PM, T.J. Crowder t...@crowdersoftware.com
wrote:
In the current default operator strawman[1], the operator is ??, e.g.:
a = b ?? 5;
is shorthand for
a = b !== undefined ? b : 5;
I missed this discussion. What validates the introduction of this
syntax over the equally simple and already possible `a = b || 5`? Is
the comparison to `undefined` (and why not `==null` as well??) really
worth the introduction (and subsequent loss of future usage) of the
double question mark? Whatever it's usual name is (double wat?).
If b is falsey (0, false, null), it'll use the 5, even though you only
intended it to be used when b is undefined.
undefined is special-cased here because it's an extremely common
value to check against. It's used when an argument isn't supplied, or
when you try to pull a non-existent property off of an object.
A non-supplied argument is a use-case that is already covered by
default parameters.
On the other hand, non-existent properties are a use-case.
CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o =
a: 1
b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = {
a: 1,
b: 2
};
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null,
like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties
use-case should be undefined-specific or null-specific (or both).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Updated. Sorry, no ||| instead of ??. Instead, inspired by Wes's GCC reminder, I kept the ?? operator but re-spelled it as ?: and made ??= be spelled ?=. http://wiki.ecmascript.org/doku.php?id=strawman:default_operator The semantics match only undefined. APIs use null as no-object and do not want to trigger defaulting, here or with parameter default values. This reminds me: IIRC we need to agree that an explicit undefined actual argument triggers defaulting for parameter default values (as it would if the pdv-based code were rewritten to use ?: or ?=). /be Brendan Eich wrote: Brendan Eich wrote: LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Of course, A should be LeftHandSideExpression and B should be AssignmentExpression. This is pretty simple. We could even grant an exception and get it into ES6, IMHO. But first it needs a strawman and some discussion. Absent fast objections here, I'll co-opt the http://wiki.ecmascript.org/doku.php?id=strawman:default_operator strawman and put it on the agenda. /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: ||= is much needed?
On Tue, Jun 12, 2012 at 3:09 PM, Brendan Eich bren...@mozilla.org wrote: And (to be clear) the semantics for LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Let rval = GetValue(rref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, call PutValue(lref, rval). to assign the default value if and only if the left-hand side's current value is undefined. Wouldn't you want B to be evaluated only if A is undefined? -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 12, 2012, at 3:26 PM, John Tamplin wrote: On Tue, Jun 12, 2012 at 3:09 PM, Brendan Eich bren...@mozilla.org wrote: And (to be clear) the semantics for LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Let rval = GetValue(rref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, call PutValue(lref, rval). to assign the default value if and only if the left-hand side's current value is undefined. Wouldn't you want B to be evaluated only if A is undefined? Yes, that makes it consistent with the semantics of ? : Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Heh, I did write *roughly* :-P. Let lref = evaluate LeftHandSideExpression. Let lval = GetValue(lref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, then: Let rref = evaluate AssignmentExpression. Let rval = GetValue(rref). Call PutValue(lref, rval). Thanks, fixing and transcribing into http://wiki.ecmascript.org/doku.php?id=strawman:default_operator /be John Tamplin wrote: On Tue, Jun 12, 2012 at 3:09 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: And (to be clear) the semantics for LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Let rval = GetValue(rref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, call PutValue(lref, rval). to assign the default value if and only if the left-hand side's current value is undefined. Wouldn't you want B to be evaluated only if A is undefined? -- John A. Tamplin Software Engineer (GWT), Google ___ 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: ||= is much needed?
Ok, that (cited below) was wrong too. This should be right: http://wiki.ecmascript.org/doku.php?id=strawman:default_operator#semantics Comments welcome. Thanks again, I needed some caffeine! /be Brendan Eich wrote: Heh, I did write *roughly* :-P. Let lref = evaluate LeftHandSideExpression. Let lval = GetValue(lref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, then: Let rref = evaluate AssignmentExpression. Let rval = GetValue(rref). Call PutValue(lref, rval). Thanks, fixing and transcribing into http://wiki.ecmascript.org/doku.php?id=strawman:default_operator /be John Tamplin wrote: On Tue, Jun 12, 2012 at 3:09 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: And (to be clear) the semantics for LeftHandSideExpression ?= AssignmentExpression are roughly Let lref = evaluate A. Let lval = GetValue(lref). Let rref = evaluate B. Let rval = GetValue(rref). Throw a SyntaxError exception if the following conditions are all true: • Type(lref) is Reference is true • IsStrictReference(lref) is true • Type(GetBase(lref)) is Environment Record • GetReferencedName(lref) is either eval or arguments If lval is undefined, call PutValue(lref, rval). to assign the default value if and only if the left-hand side's current value is undefined. Wouldn't you want B to be evaluated only if A is undefined? -- John A. Tamplin Software Engineer (GWT), Google ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 12, 2012, at 11:02 AM, Brendan Eich wrote: It's possible ?? or however we spell it isn't worth adding, while ?= is. The conditional assignment to default or normalize is the prime use-case. I'm skeptical. You don't foresee f(obj.x ?? defVal) happening a lot? I do. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl thaddee@gmail.com wrote:
On the other hand, non-existent properties are a use-case.
CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o =
a: 1
b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = {
a: 1,
b: 2
};
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null,
like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties
use-case should be undefined-specific or null-specific (or both).
That's... pretty wrong. In the example above, o.c returns undefined,
not null. If CoffeeScript *actually* compiles to the code you posted,
then it only works because they're using != instead of !==, and null
and undefined are both falsey. However, it'll break if o.c is defined
and is a falsey value like 0 or false.
Try it. Put the following in your nearest console and see what it returns:
({a:1, b:2}).c === undefined
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Tue, Jun 12, 2012 at 6:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Jun 12, 2012 at 2:52 PM, Thaddee Tyl thaddee@gmail.com wrote:
On the other hand, non-existent properties are a use-case.
CoffeeScript provides a similar feature, but for null properties.
For example, the following:
o =
a: 1
b: 2
alert o.c?.d
compiles to:
var o, _ref;
o = {
a: 1,
b: 2
};
alert((_ref = o.c) != null ? _ref.d : void 0);
Special-casing undefined makes as much sense as special-casing null,
like CoffeeScript does.
My point is that it is not obvious whether the non-existent properties
use-case should be undefined-specific or null-specific (or both).
That's... pretty wrong. In the example above, o.c returns undefined,
not null. If CoffeeScript *actually* compiles to the code you posted,
then it only works because they're using != instead of !==, and null
and undefined are both falsey. However, it'll break if o.c is defined
and is a falsey value like 0 or false.
Try it. Put the following in your nearest console and see what it returns:
({a:1, b:2}).c === undefined
CoffeeScript's property checking returns undefined if the property
is either undefined or null, and returns the property itself
otherwise.
If the property is false or 0, it returns the property (either false or 0).
I don't understand why you say it breaks if o.c is a falsey value like
0 or false.
The following code:
Boolean.prototype.d = 'Property'
o =
a: 1
b: 2
c: false
alert o.c?.d
will show Property, as we'd expect.
My point still stands. Being undefined-specific is arbitrary.
CoffeeScript could have been undefined-specific; they were
undefined + null-specific, which I believe makes more sense.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Fwd: ||= is much needed?
This message seems to have disappeared from the archive and since I
referred to it in
http://wiki.ecmascript.org/doku.php?id=strawman:default_operator I wanted
to make sure a record existed.
Rick
-- Forwarded message --
From: Ryan Florence rpflore...@gmail.com
Date: Tue, Jun 12, 2012 at 11:45 AM
Subject: Re: ||= is much needed?
To: Rick Waldron waldron.r...@gmail.com
Cc: David Bruant bruan...@gmail.com, es-discuss@mozilla.org
I use ||= very regularly in ruby and coffeescript, both of which have
default arguments.
I definitely agree that default arguments are a decent alternative. I
can't recall examples where it wouldn't be enough. Do you have use cases
where you would use ||= and default argument values couldn't be used?
Its super handy for caching and late/dynamic initialization of object
properties.
var events = {
_callbacks: {},
on: function (topic, callback) {
(this._callbacks[topic] ||= []).push(callback);
...
},
...
};
It's also useful for settings object defaults, especially for expensive
settings that you don't want to calculate in some `defaults` object that is
merged into the settings.
function ajaxWithError (settings) {
settings.method ||= 'POST';
settings.elementPosition ||= this._getElementPositions();
settings.somethingWithInitialization ||= (function(){
var thing = new Thing();
thing.foo = settings.foo;
return thing;
})();
...
};
The ||= (function(){})() should remind any rubyist of `||= begin ... end`
which is beloved by many.
So yeah, I think its really useful outside of default arguments.
- Ryan Florence
On Jun 12, 2012, at 9:06 AM, Rick Waldron wrote:
ahah, I asked the same question very recently [1]. Answer by Brendan Eich
[2].
I definitely agree that default arguments are a decent alternative. I
can't recall examples where it wouldn't be enough. Do you have use cases
where you would use ||= and default argument values couldn't be used?
David
[1] https://twitter.com/DavidBruant/status/210654806732324864
[2] https://twitter.com/BrendanEich/status/210750515808706561
___
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: ||= is much needed?
On Jun 12, 2012, at 5:57 PM, David Herman dher...@mozilla.com wrote: On Jun 12, 2012, at 11:02 AM, Brendan Eich wrote: It's possible ?? or however we spell it isn't worth adding, while ?= is. The conditional assignment to default or normalize is the prime use-case. I'm skeptical. You don't foresee f(obj.x ?? defVal) happening a lot? I do. Dave No need to foresee. We have Ruby precedent along with CoffeeScript in sight. We also have JS as it is used today, where || is used almost exclusively on the callee side to supply default values. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
Ryan Florence wrote: But if we're adding ?= because we're adding ?: maybe its okay to add ||= while we're at it? That said, I would hate to see ?= get derailed because ||= is dumb. Dumb is too strong. How about YAGNI? Every use-case of || I've seen in JS (almost all with the result of || the RHS of an = op) really wants ?=. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
On Jun 12, 2012, at 7:41 PM, Ryan Florence wrote: I'm skeptical. You don't foresee f(obj.x ?? defVal) happening a lot? I do. I can't speak for the world but I've never seen anybody do f(val ||= defVal) in Ruby or CoffeeScript. But I'm not talking about ||=. I'm talking about the analog of ||. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote: My point still stands. Being undefined-specific is arbitrary. CoffeeScript could have been undefined-specific; they were undefined + null-specific, which I believe makes more sense. Can you make the full argument? I'm genuinely undecided on this question, and having trouble deciding on the criteria. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ||= is much needed?
People don't default on the caller side (at the callsite) much, in my
experience. Dave may be seeing other sources, but it's extremely rare in
my experience to see
foo(arg1 || callers_idea_of_default_arg1_value);
whereas we all see
function foo(a, b, c) {
a = a || default_a;
b.x = b.x || default_b_x;
b.y = b.y || default_b_y;
c.z = function (w) {
// long body here
}
...
}
Plain and destructuring parameter default values help with a and b
(provided the default_* expressions are small and don't require other
locals that are computed based on complex conditions, etc.). c.z is
harder to fit in the parameter list neatly.
It may be that ?= won't see much use, once p.d.v.s are in. Hence the
strawman status while p.d.v.s are in ES6.
/be
Ryan Florence wrote:
Sorry, I misunderstood.
CoffeeScript has ? (no ternary, so its doable there) but I haven't
seen it used much.
On Jun 12, 2012, at 11:14 PM, David Herman wrote:
On Jun 12, 2012, at 7:41 PM, Ryan Florence wrote:
I'm skeptical. You don't foresee
f(obj.x ?? defVal)
happening a lot? I do.
I can't speak for the world but I've never seen anybody do f(val ||=
defVal) in Ruby or CoffeeScript.
But I'm not talking about ||=. I'm talking about the analog of ||.
Dave
___
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: ||= is much needed?
I think it’d be handy when you are taking apart objects (e.g. JSON data). However, you do have the option of merging in default values (e.g. via http://documentcloud.github.com/underscore/#defaults ). On Jun 13, 2012, at 7:52 , Brendan Eich wrote: People don't default on the caller side (at the callsite) much, in my experience. Dave may be seeing other sources, but it's extremely rare in my experience to see foo(arg1 || callers_idea_of_default_arg1_value); -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
