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

Herby Vojčík herby at mailbox.sk
Thu Jun 21 10:21:21 PDT 2012

Brendan Eich wrote:
> 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.

Adn that is precisely what I proposed under name [[NullPatternObject]]. 
So all of (1), (3), (4) and (5) are void.

> 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.

Smalltalk nil is a bit different from Null Pattern. I proposed Null 
pattern (optimized off when not actually needed in the equation, but 
exposed when needed).

> 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.

Such a [[NullPattternObject]] can ToBoolean to false. No problem I see.

> 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


More information about the es-discuss mailing list