Re: ||= is much needed?
Yes, we could make ?? and ??= do the same for null as for undefined. I'm not sure that's the right choice, but it's a choice. Introducing yet another way to think about values in ES is not going to help most programmers. We already have to think about thinks like undefined and falsey -- what's been proposed here is an operator that mysterious works on something halfway between the two. Some folks may not see the need to differentiate between the two, but as somebody who talks to databases with ES -- there is a world of difference between null and undefined. 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: Existential operator (was: ||= is much needed?)
This is related to what I was trying to figure out in the more fun with undefined thread, maybe it is wrong or have too many impact but I was about to suggest : 8.9.1 GetValue (V) ... 5. If IsUnresolvableReference(V), return undefined 11.2.1 Property Accessors Runtime Semantics: Evaluation ... 3. If baseValue is an abrupt completion or undefined, return baseValue. Why not, instead of adding ? operator ? Le 18/06/2012 07:11, Brendan Eich a écrit : Sorry, meant to start a new thread for: http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator As the Syntax section hints, we can't also adopt CoffeeScript's ?( variant, which enables foo.bar?(args, go, here).baz and the like. The C syntax heritage prevails. /be Brendan Eich wrote: David Herman wrote: On Jun 15, 2012, at 5:57 PM, satyr wrote: On Sat, Jun 16, 2012 at 4:33 AM, David Herman dher...@mozilla.com mailto:dher...@mozilla.com wrote: As for null, I can see how there's confusion about whether to use null vs undefined, and so I can see why CoffeeScript would just try to blur the distinction between them. Not just for blurring. Rejecting `null` is essential for CoffeeScript's existence due to `?.`, the soak/safe access operator. I think you could make a case for ?. defaulting for both but ?? defaulting only undefined. The case goes something like this: - The purpose of ?? is to provide a default value when no value was provided. The way to say no value in JavaScript is undefined. - The purpose of ?. is to fail soft when doing a property lookup. Both null and undefined throw when doing a property lookup. Agreed. This is one choice, it's plausible because of the distinction between defaulting (which requires intentional passing of a please default sentinel value, or not passing a trailing actual argument) and soaking up null-or-undefined. Yes, we could make ?? and ??= do the same for null as for undefined. I'm not sure that's the right choice, but it's a choice. For foo.bar?.baz, though, the clearer choice is to avoid throwing, which means evaluating to undefined if foo.bar is missing (evaluates to undefined) *or* has a value not coercible to object type (null or undefined). See http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator /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 -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
Aymeric Vitte wrote: Why not, instead of adding ? operator ? You mean ?. here, I assume. The answer is because what you propose is an incompatible change to ECMA-262 (all editions) and JS back to its birth, which lets programs that throw currently continue to run, with possibly disastrous consequences (undefined flowing into the bank-balance database as NaN). There is no way that this kind of potentially-bug-hiding behavior should be the default semantics. It must be explicitly opted-into via new syntax. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
OK, ?. is enough and good Le 18/06/2012 16:48, Brendan Eich a écrit : Aymeric Vitte wrote: Why not, instead of adding ? operator ? You mean ?. here, I assume. The answer is because what you propose is an incompatible change to ECMA-262 (all editions) and JS back to its birth, which lets programs that throw currently continue to run, with possibly disastrous consequences (undefined flowing into the bank-balance database as NaN). There is no way that this kind of potentially-bug-hiding behavior should be the default semantics. It must be explicitly opted-into via new syntax. /be -- jCore Email : avi...@jcore.fr Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Protected properties using Name objects
I agree with David: is this use case sufficiently common/needed to require such deep extensions to Javascript's object model? Especially the interplay between writable configurable is already complex. Adding more knobs should not be done lightly. Accessors seem like a fine abstraction for protected attributes. I can't imagine their overhead to be prohibitive? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator (was: ||= is much needed?)
This proposal augments the default operator by adding syntax to avoid
accessing a missing property, specifically ?. for getting and setting a
property from a reference base that might be undefined or null: [1]
The specified semantics of proposal actually does more than avoid accessing a
missing property. It also avoids accessing a property of a missing object.
For example,
function f() {
var foo; //oops, I forgot to write the initializer
expression
return foo?.bar;//returns undefined because foo evaluates to undefined.
foo.bar would throw
}
This seems slightly and possibly significantly different from a situation like:
function f(foo={ }) {
return foo?.bar;//returns value of foo.bar or undefined if property bar
does not exist, just like foo.bar
}
In particular, it has the affect of possibly propagating the detection of a
simple editorial error like a forgotten initializer further from its place of
occurrence.
At the least, this behavior probably should be clarified in the description
The inability to use ?. meaningfully in a function call context would seem to
make this a only half useful feature. I suspect many people will initially try
to write something like
foo?.bar()
with the expectation that the call will be skipped if bar doesn't exist.
These may be an alternative semantics that might address both of the above
issues. Consider:
The semantics of ?. could be defined in terms of a new Reference variant (a
Conditiional Reference):
Let baseReference be the result of evaluating MemberExpression.
If Type(baseReference) is Reference and IsConditionalReference(baseReference)
is true, then let baseValue be GetUnconditionalValueOrMissing(baseReference)
Else let baseValue be GetValue(baseReference).
If baseValue is null or undefined, then throw a TypeError exception.
Let propertyName be the result of evaluating IdentifierName.
If the syntactic production that is being evaluated is contained in strict mode
code, let strict be true, else let strict be false.
Return a value of type Conditional Reference whose base value is baseValue and
whose referenced name is propertyName, and whose strict mode flag is strict.
Missing is an internal value that designates an attempt to access a missing
value.
GetUnconditionalValueOrMissing(R) where R is a Reference is defined as
Let value be GetValue(R).
If value is null or undefined then if IsConditionalReference(R) is true hen
return Missing.
Return value.
and GetValue would get the following new steps:
2.5 If IsConditionalReference(V) is true then If base is Missing then then
return undefined.
Function call semantics (11.2.3) could then be modified with the existing step
2 replaced with
2.1 Let func be GetUnconditionalValueorMIssing(ref).
2.2 If func is MIssing, then return undefined.
With these changes, the following would evaluate to undefined:
var foo ={}, foo2;
foo?.bar()
but
foo.bar();
would throw.
But note that both
foo2.bar()
foo2?.bar()
would throw reference error exceptions because of line 4 of the ?. semantics n
(and the existing .). In other words, a variable reference that resolves to
undefined or null when used as a base of ?. doesn't be a pass.
However, the two above changes a separable with want one, but not the other.
Allen
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
