Existential operator (was: ||= is much needed?)

[Brendan Eich]

Replying to both Herby and Domenic here.

Domenic Denicola wrote:
> On Jun 21, 2012, at 3:22, "Herby Vojčík"<herby at mailbox.sk>  wrote:
>
>> Brendan Eich wrote:
>>> Herby Vojčík wrote:
>>>> I feel there is objection to introduce magical [[NullPatternObject]]
>>>> into language, but all of CS-style soft-accesses could be solved very
>>>> cleanly and consistently.
>>> No, because (a) the overhead of a new object is too high; (b) with any
>>> kind of suffix-? or suffix-.? as you proposed it would be observable
>>> that you get a new object instead of short-circuiting to undefined --
>>> the new object is exposed in the language.
>> What's wrong with it per se?

1. The overhead, which is not wanted in almost all cases. Then saying 
"implementations may optimize" simply makes a de-facto standard with 
high implementation cost inevitable. We should normatively spec what 
CoffeeScript does -- boolean result for suffix-? or anything like it -- 
or else add a singleton "Nil" object that can be reused.

2. It's not what CoffeeScript does.

3. For foo?.bar if foo is not bound or has null or undefined value, if I 
understand correctly, you propose to use ({}) instead. This does not 
provide "indefinite soak", where foo?.bar.baz.quux silently 
short-circuits to undefined value on unbound or ==-null foo. And if 
Object.prototype.bar exists, foo?.bar where foo is unbound/==-null will 
wrongly evaluate to Object.prototype.bar's value.

4. Likewise foo?(bar) or however it might be spelled will try to invoke 
an empty fresh object, throwing a TypeError -- not what we want.

5. if (foo.?) as Herby proposed evaluates to a truthy fresh object if 
foo is unbound or has ==-null value. CoffeeScript and any sane 
interpretation of suffix-? or variant spelling wants falsy if not false 
result for unbound/==-null foo.

These are problems _per se_. But see below on the Nil singleton idea.

>>   Let it be exposed, let people use it. Some of uses will be wrong, they will eventually die, some of them will be fine, they survive (no need to add keyword or API for it, null.? yields it and it is usably short).
>>
>> And BTW, if foo.? is too long and abuse of dot, you can use for example postfix tilde to get foo~.bar, foo.bar~(), "bar" in foo~ etc.
>>
>>> /be
>> Herby
>
> Language-level support for the null object pattern would be pretty excellent!

Depends on what you mean by "null object".

I don't believe anyone wants a fresh empty object for each ? ?. ?( or 
however we spell the variants. There's no evidence for this from 
CoffeeScript. A fresh object as default value breaks indefinite soak and 
may expose proto-properties (3), breaks the ?( call variant (4), and 
breaks boolean tests of suffix-? expressions (5), as far as I can tell.

>   I think, given the CoffeeScript grep stats (not to mention common `options = options || {}` code), people are definitely using ? in that capacity.

Sure, no one argues otherwise. The minority use-cases could wait, but we 
should discuss them before deferring. Agree with all that. But a "Null 
object" meaning fresh empty object is no solution, per (1-5) above.

>   The possibility of introducing something elegant like this seems like exactly why getting in only property-access ?. would be a mistake.

What is elegant may be something you haven't actually described: a "Nil 
singleton", a proxy actually, which can soak up indefinite gets, sets, 
and calls. It must be a singleton to avoid the overhead problem.

This Nil proxy would take the place of the concealed Reference type that 
Allen suggested. It has some appeal to fans of Smalltalk who message nil.

Such a Nil proxy still cannot masquerade as false, though, and that is 
required for suffix-? testing. An object that can convert to false 
awaits value objects 
(http://wiki.ecmascript.org/doku.php?id=strawman:value_objects) married 
with proxies to make value proxies.

I've argued in the past against coupling proposals and chaining risk of 
non-acceptance, so I don't think the existential operator and variants 
should depend on such a Nil proxy singleton idea. Happy to discuss it 
more, but as a practical matter I would want it concealed in 
http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator and 
exposed only in a separate proposal, once we have value objects and 
value proxies (assuming we get them).

/be