Catchall invocation for 'null' and 'undefined' (or: how to be a disruptive influence in 3 easy steps)
All -
I sent this about 1.5 weeks ago, but have gotten no responses. I can
attribute this to 2 possible items:
-
I made the mistake of replying to an existing message so this one
got buried under a thread it shouldn't have. -
Folks were so horrified as to what I was asking for that they
really just wished I would go away :-).
I'll repeat the message here. If the answer is #2, please let me know
and I'll crawl back under my rock :-).
Cheers,
- Bill
All -
Well, Sister Eugenia always did say I was a disruptive influence in
grade school - guess I haven't changed much :-).
Let me throw another idea into the mix and churn the pot a bit more.
Many moons ago when I was a Smalltalker, I always liked the fact that
'nil' in Smalltalk was a singleton instance of UndefinedObject... and
you could add methods to UndefinedObject :-).
Like... doesNotUnderstand.
When I switched to JS, I found out that 'null' and 'undefined' were
'special' and weren't instances of anything I could add methods to
(cue wailing and gnashing of teeth).
I always thought it would be most interesting if the following were
true: 'null' was the singleton instance of the Null type and
'undefined' was the singleton instance of the Undefined type.
Then, I could do the following (which would have saved me a lot of
debugging time over the years):
(Using the older noSuchMethod syntax):
Null.prototype.noSuchMethod = function (id, args) { alert('you were a bad boy and tried to send ' + id + ' to null'); }
Undefined.prototype.noSuchMethod = function (id, args) { alert('you were a bad boy and tried to send ' + id + ' to undefined'); }
My business partner Scott has bugged Brendan about this in the past
and he mentioned that ES3 was too set in its ways to do anything like
this, but I figured maybe with Harmony on the horizon, the issue could
be revisited :-). I have no idea regarding the implications of such a
change and therefore leave it to you all to consider those implications.
Thoughts?
On Fri, May 15, 2009 at 10:45 AM, William Edney <bedney at technicalpursuit.com> wrote:
Then, I could do the following (which would have saved me a lot of debugging time over the years):
Null.prototype.noSuchMethod = function (id, args) { alert('you were a bad boy and tried to send ' + id + ' to null'); }
Undefined.prototype.noSuchMethod = function (id, args) { alert('you were a bad boy and tried to send ' + id + ' to undefined'); }
This seems like something that can be addressed by "quality of implementation" today, at least as far as error messages go. I think it's entirely possible for the error paths to give more context, so I'm wondering if there are other significant use cases for creating Null and Undefined.
(And would you then want toString and valueOf hooks to be honoured? Would Undefined and Null be truthy or falsy? Boolean is enough of a mess on that score...)
Mike
Shaver raised the general point that Object types cannot convert to
any boolean value other than true, per ES1. I've mentioned before that
this was not what Netscape's JS implementation did, but in order to
avoid multiple implicit conversions to boolean due to chained && and
||, we agreed to make ToBoolean(obj) = true for all Object-typed (ES1
term: any non-primitive) obj.
We'd have to revisit this, at least.
My sense is that most people don't feel strongly enough to put in the
work to develop this Smalltalk nil idea so that it is both complete
and compatible. The Java-ish null (really, C-ish) design decision is
hard to revoke. Catchalls are not enough to change null and undefined
to be of Object type (again that pesky ES spec language).
I regret not making everything an object, FWIW. "Make it look like
Java" + lazy/fast machine types for numbers + zero time to implement
in May 1995.
All -
Well, Sister Eugenia always did say I was a disruptive influence in
grade school - guess I haven't changed much :-).
Let me throw another idea into the mix and churn the pot a bit more.
Many moons ago when I was a Smalltalker, I always liked the fact that
'nil' in Smalltalk was a singleton instance of UndefinedObject... and
you could add methods to UndefinedObject :-).
Like... doesNotUnderstand.
When I switched to JS, I found out that 'null' and 'undefined' were
'special' and weren't instances of anything I could add methods to
(cue wailing and gnashing of teeth).
I always thought it would be most interesting if the following were
true: 'null' was the singleton instance of the Null type and
'undefined' was the singleton instance of the Undefined type.
Then, I could do the following (which would have saved me a lot of
debugging time over the years):
(Using the older noSuchMethod syntax):
Null.prototype.noSuchMethod = function (id, args) { alert('you were a bad boy and tried to send ' + id + ' to null'); }
Undefined.prototype.noSuchMethod = function (id, args) { alert('you were a bad boy and tried to send ' + id + ' to undefined'); }
My business partner Scott has bugged Brendan about this in the past
and he mentioned that ES3 was too set in its ways to do anything like
this, but I figured maybe with Harmony on the horizon, the issue could
be revisited :-). I have no idea regarding the implications of such a
change and therefore leave it to you all to consider those implications.
Thoughts?