Replying to both Herby and Domenic here.
Domenic Denicola wrote:
On Jun 21, 2012, at 3:22, "Herby Vojčík"<[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
