Consistency in The Negative Result Values Through Expansion of null's Role
Peter van der Zee
ecma at qfox.nl
Thu Aug 16 09:38:00 PDT 2012
On Thu, Aug 16, 2012 at 12:02 AM, Erik Reppen <erik.reppen at gmail.com> wrote:
> So for the sake of consistency/sanity in future methods, at least, how about
> establishing the following guidelines somewhere on the usage of these
> * More specific negative-result values are reserved for simple statements
> and very simple one-arg methods that operate directly on the value of your
> * Just about anything else returns null for non-positive-result scenarios
> where more specific returns don't necessarily clarify and could confuse
> * Ditch consistent typing approaches if that's not a lower-level perf thing.
Could introduce a "fail" primitive type whos primitive value is the
(possibly empty) message explaining why it/what went wrong. The value
would always behave as false except for toString() cases and strict
comparison. Could even return `false` for typeof and use a .isFail()
to detect. Probably some more semantics to hash out, but I think you
get the gist of it.
I'm sure nobody wants to add another type to the language though ;)
It's just an idea.
More information about the es-discuss