Re: Default operator strawman - ||| rather than ??
On 16 June 2012 01:44, Brendan Eich bren...@mozilla.com wrote: T.J. Crowder wrote: On 15 June 2012 22:22, Brendan Eich bren...@mozilla.org mailto: bren...@mozilla.org wrote: If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. Who said it was? You summarized Herby to that effect: Ah, sorry -- apparently copy-and-paste doesn't stick in the memory, I didn't recall that phrasing. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Brendan Eich wrote: In fact, I don't think I was pushing any particular syntax. I think I was clear about asking _whether_ people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question? I was describing the hazards of adding syntax that wouldn't hurt. Syntax should be added only when it clearly helps: * It brings new semantics not expressible in the language (let, const, modules, generators). * It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded. I'm from different school of thinking which is probably very incovenient in spec-thinking. But I feel strongly that there should be one more category: * It is an affordance with very little or no new semantic for an uncommon pattern which by its formalizing and makes godel-accessible (in the sense comprehensible by one's mind) space covered by the language much greater. (I'm talking about mixins / traits, mustache+richer data semantics, ... Things that can be done, but the price is hard, so they are not used. But that goes directly against paving the cowpath and no novelties. Basically what I am advocating here probably are novelties. :-/ ) /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Herby Vojčík wrote: Brendan Eich wrote: In fact, I don't think I was pushing any particular syntax. I think I was clear about asking _whether_ people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question? I was describing the hazards of adding syntax that wouldn't hurt. Syntax should be added only when it clearly helps: * It brings new semantics not expressible in the language (let, const, modules, generators). * It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded. I'm from different school of thinking which is probably very incovenient in spec-thinking. But I feel strongly that there should be one more category: * It is an affordance with very little or no new semantic for an uncommon pattern which by its formalizing and makes godel-accessible s/and// (in the sense comprehensible by one's mind) space covered by the language much greater. (I'm talking about mixins / traits, mustache+richer data semantics, ... Things that can be done, but the price is hard, so they are not used. But that goes directly against paving the cowpath and no novelties. Basically what I am advocating here probably are novelties. :-/ ) /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: Default operator strawman - ||| rather than ??
I think the original thrust of this thread may have got lost a bit in the (useful) discussion of null and undefined, so coming back to the original point: On 12 June 2012 16:29, 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; 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 Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't _need_ it), Brendan's (too thin)[1], and Herby's (wouldn't hurt)[2]. (Speaking syntactically, I think we all agreed in the other thread that ||| [above] won't work for the infix, because the assignment form just becomes too confusing, as Wes pointed out.[3]) [1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023468.html [2] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023510.html [3] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023386.html -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Fri, Jun 15, 2012 at 6:28 AM, T.J. Crowder t...@crowdersoftware.com wrote: Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't _need_ it), Brendan's (too thin)[1], and Herby's (wouldn't hurt)[2]. Since you are asking for opinions. I don't want it. It doesn't carry its own weight. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On 15 June 2012 18:05, Erik Arvidsson erik.arvids...@gmail.com wrote: Since you are asking for opinions. I don't want it. It doesn't carry its own weight. I was, and that includes opinions against. Thanks! -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Erik Arvidsson wrote: On Fri, Jun 15, 2012 at 6:28 AM, T.J. Crowdert...@crowdersoftware.com wrote: Does anyone have an opinion on a second ternary a'la the above (syntax notwithstanding). So far we have only my opinion (I like it and would have uses for it; I don't _need_ it), Brendan's (too thin)[1], and Herby's (wouldn't hurt)[2]. Since you are asking for opinions. I don't want it. It doesn't carry its own weight. If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise. So the summary (sorry if it didn't do Herby's position justice; I'm using it as a whipping boy here) of wouldn't hurt is simply not an argument for new operators to shorten hard cases. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On 15 June 2012 22:22, Brendan Eich bren...@mozilla.org wrote: If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. Who said it was? New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise. I'm sorry: botched?! What exactly is botched about this? In fact, I don't think I was pushing any particular syntax. I think I was clear about asking _whether_ people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question? -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
T.J. Crowder wrote: On 15 June 2012 22:22, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: If everyone's opinion carries weight, then we are tied :-P. Kidding. But aside from opinions and their weight, we have a problem if wouldn't hurt is the answer for syntax proposals. Who said it was? You summarized Herby to that effect: Herby's (wouldn't hurt)[2]. ... [2] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023510.html New syntax does hurt. It hurts by requiring a transpiler or full compiler to target old browsers. It hurts if it's botched, because you cannot polyfill to patch it. It costs inordinately compared to deferring and seeing if enough use-cases arise. I'm sorry: botched?! What exactly is botched about this? You are misreading my generic words. I'm not talking about a proposal of yours, or of mine. In fact, I don't think I was pushing any particular syntax. I think I was clear about asking _whether_ people saw value in the semantics of it, not the syntax. It's fine if people don't see value; is there a problem with asking the question? I was describing the hazards of adding syntax that wouldn't hurt. Syntax should be added only when it clearly helps: * It brings new semantics not expressible in the language (let, const, modules, generators). * It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Brendan Eich wrote: * It brings new semantics not expressible in the language (let, const, modules, generators). * It is an affordance without new semantics for a common pattern that's verbose and error-prone when open-coded. Classes (maximally minimal, mainly for extends and super) is a prime example of the second bullet, IMHO. Apologies if my reply seemed targeted at you, or Herby for that matter. I was soap-boxing against the wouldn't hurt summary-argument. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
My two sense. In my experience (large applications, rather than tight
libraries), distinguishing between null and undefined is the exception, not
the rule. When it is distinguished, as often as not the author would be
more correct in either including null or making an property existence
check (foo in bar) rather than an explicit check for undefined.
On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users
immediately tested o.p != null to existing-check. There was even some
confusion where missing array elements in primordial JS evaluated to null
not undefined. Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist,
though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-**optimization of storing null rather
than using delete doesn't argue for defaulting based on LHS value in {null,
undefined}.
Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or
biology. Not just Homer Simpson Life is just a bunch of things that
happen randomness, mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null
and undefined are confusingly similar, in part due to being ==. This is
true, but I still do not see actual use-cases where null is passed into
code that uses || to select a default value. Would love to see such
real-world code.
/be
__**_
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: Default operator strawman - ||| rather than ??
In our experience writing large apps, the distinction is useful. Undefined
means I forgot to do something (e.g. set a property or pass an argument); null
means I tried to get something but it didn't exist.
Very roughly, it becomes undefined = caller error outside of my control, null =
my error and I should use the API more correctly.
On Jun 14, 2012, at 11:27, John Lenz
concavel...@gmail.commailto:concavel...@gmail.com wrote:
My two sense. In my experience (large applications, rather than tight
libraries), distinguishing between null and undefined is the exception, not the
rule. When it is distinguished, as often as not the author would be more
correct in either including null or making an property existence check (foo in
bar) rather than an explicit check for undefined.
On Wed, Jun 13, 2012 at 11:18 AM, Brendan Eich
bren...@mozilla.orgmailto:bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users
immediately tested o.p != null to existing-check. There was even some confusion
where missing array elements in primordial JS evaluated to null not undefined.
Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they exist,
though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-optimization of storing null rather than
using delete doesn't argue for defaulting based on LHS value in {null,
undefined}.
Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or biology.
Not just Homer Simpson Life is just a bunch of things that happen randomness,
mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that null and
undefined are confusingly similar, in part due to being ==. This is true, but I
still do not see actual use-cases where null is passed into code that uses ||
to select a default value. Would love to see such real-world code.
/be
___
es-discuss mailing list
es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.orgmailto: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: Default operator strawman - ||| rather than ??
On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola dome...@domenicdenicola.com wrote: In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist. null is intentional, its presence is explicit -- doesn't this imply that something _does_ exist? (...and its value is null) eg. https://gist.github.com/2926029 Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
On Jun 14, 2012, at 14:03, Rick Waldron waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote: On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: In our experience writing large apps, the distinction is useful. Undefined means I forgot to do something (e.g. set a property or pass an argument); null means I tried to get something but it didn't exist. null is intentional, its presence is explicit -- doesn't this imply that something _does_ exist? (...and its value is null) eg. https://gist.github.com/2926029 Rick Right, I wasn't exactly clear—I meant more the case of e.g. nothing exists in the database, so I gave you back a null or even there wasn't any error, so I called you back with a null as the first param. ___ 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:17 PM, David Herman dher...@mozilla.com wrote: 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. undefined and null share a lot of behavior that other falsy values don't have. The most critical one is to throw a TypeError on some occasions, including when invoking the abstract ToObject operation. Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance. This lets the user know when a parameter was meant to be set to nothing, and when we should use a default parameter instead. Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common. On the other hand, we often want to react in a certain way if the parameter is not set, either because it was not supplied or because it was set to null. Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null. Having a way to deal with those return values by providing a default value would be nice. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Thaddee Tyl wrote: On Tue, Jun 12, 2012 at 10:17 PM, David Hermandher...@mozilla.com wrote: 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. undefined and null share a lot of behavior that other falsy values don't have. The most critical one is to throw a TypeError on some occasions, including when invoking the abstract ToObject operation. Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance. Yes. I find this pattern a little smelly, though. It is an optimization for V8 - delete foo.x changes foo to plain slow hashtable, but foo.x = null does not. This lets the user know when a parameter was meant to be set to nothing, and when we should use a default parameter instead. Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common. But here, it is semantic difference - null means nothing, chosen by will. Undefined means nothing, as a consequence of not being defined. On the other hand, we often want to react in a certain way if the parameter is not set, either because it was not supplied or because it was set to null. I find the or here a bit misleading - to react if parameter is not set is to react to undefined. Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null. Object.getPrototypeOf(...) return null for a reason. It is not semantically undefined, it is very well defined, being the prototype chain stops here, no more parents. Having a way to deal with those return values by providing a default value would be nice. As I see it, it is much clearer (in the good code design and style sense) to only react to undefined. But under paving the cowpaths philosophy, I am afraid null+undefined is what will be considered as the implementation. Herby P.S.: It also saves more code if ??/?= will react to undefined. Properly testing undefined needs typeof foo === undefined while properly testing for undefined+null only needs foo == null . P.P.S.: It would be helpful if delete could be made fast in V8 and foo=null discouraged... though I can't imagine how. ___ 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:33 PM, Thaddee Tyl thaddee@gmail.com wrote:
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.
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them. Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
~TJ
___
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 11:44 PM, Thaddee Tyl wrote: Besides, it often has a similar meaning: I have seen in a lot of code a de-facto standard wherein null is used to indicate a value that is voluntarily undefined. You can see this pattern all over node.js code, for instance. I *think* this is the key point, but I'm still trying to figure out the implications. I believe you're right, and I think it calls into question the undefined means no-value, null means no-object mantra. In practice, I think it's really undefined means uninitialized, null means no-value. Harmony's default parameters will make this easier, while letting a null value through -- which will make this pattern even more common. This confuses me. If default parameters *don't* treat null as requiring a default, won't that work against this pattern? Besides, the null value can be obtained from the standard library, when calling certain methods. Object.getPrototypeOf(...), string.match(...), even calling the toJSON method of a Date can return null. Having a way to deal with those return values by providing a default value would be nice. That's a pretty strong argument IMO. Dave, still mulling ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default operator strawman - ||| rather than ??
Tab Atkins Jr. wrote:
Okay, further testing shows that my knowledge was incomplete. Null
and undefined compare as double-equal, but neither are double-equal to
other falsey values.
This is intentional, believe it or don't :-P.
In ancient days, void 0 was the only way to spell undefined, and users
immediately tested o.p != null to existing-check. There was even some
confusion where missing array elements in primordial JS evaluated to
null not undefined. Argh, I had made myself forget that, now I remember.
However, my argument stands - being undefined-specific is not
arbitrary, because that's what is actually returned by such things.
Both args without values and properties that don't exist give the
value undefined when you try to reference them.
Agree still. I do not see use-cases for including null. Maybe they
exist, though -- someone please cite some github-hosted JS.
Even the Node workaround/premature-optimization of storing null rather
than using delete doesn't argue for defaulting based on LHS value in
{null, undefined}.
Using a double-equal
check against null to test for whether something is undefined only
works because double-equal is pretty screwed up.
It is screwed up but for reasons. Bad reasons, kind of like history or
biology. Not just Homer Simpson Life is just a bunch of things that
happen randomness, mind you! :-P
The most principled reason I've heard, IIRC from @jashkenas, is that
null and undefined are confusingly similar, in part due to being ==.
This is true, but I still do not see actual use-cases where null is
passed into code that uses || to select a default value. Would love to
see such real-world code.
/be
___
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: 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: 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: 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
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
