The prefix `?` for an absorbing Nil value sounds good. The semantics of `delete` may need clarifying; what should the following construct do?
`delete ?a.b.c` Most intuitive would be to not raise an error and return true if either the `b` or `c` properties are missing, whether or not in strict mode. Does that hold up? Nick On 7 April 2015 at 19:54, Herby Vojčík <[email protected]> wrote: > > > Kevin Smith wrote: > >> We should perhaps review this old thread: >> >> https://esdiscuss.org/topic/fail-fast-object- >> destructuring-don-t-add-more-slop-to-sloppy-mode >> >> for another possible way to avoid non-compositionality. (Look for the >> suggestion about "Nil". It's basically an exotic falsey object which >> returns itself for any property lookups or calls.) >> > > Going a bit deeper this way, this thing (changing ref to Nil which always > returns Nil upon call, construct and get, and getting back undefined when > value is needed) have nicely separated concerns: > > Let's say '?foo', as an unary oper > ator, when foo is a reference, returns Nil when foo is reference to null > or undefined, otherwise leaves it unchanged. Then: > > ?a.b.c just works, > ?d() just works, > new ?e[i]() just works, etc,. since ref is changed to Nil if the thing is > null/undefined, it propagates through calls and gets, then changes itself > to undefined value. The priority of ? must be pretty high, though, to only > apply to nearest token. > > Plus, it can be used for "normalizing" null/undefined to undefined: > > var normalizedFoo = ?foo; > > Seems sort of nice that it is separated and there are no special > operations for ?., ?(, ?[. > > Herby > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
