Does not understand message inconsistency
Why is UndefinedObject version of "did not understand" so different from
others?
It also inverts the object message paradigm.
Thanks
Aik-Siong Koh
description
"Returns a textual description of the exception (based on the
message instance variable). If message is nil, it returns the
defaultDescription instead."
message ifNil: [ ^ self defaultDescription ].
message lookupClass == UndefinedObject ifTrue: [
^ message selector printString , ' was sent to nil' ].
^ 'Instance of ' , message lookupClass printString
, ' did not understand ' , message selector printString
I think it's because nil is pretty special--this is the equivalent of a
NullPointerException or similar in other languages (even though in fact nil
is an object like any other, it is usually a different type of semantic
error on the part of the programmer than with any other class).
UndefinedObject is also a pretty long class name, so it's nice to leave
that out. But I would be all in favor of making it "nil did not understand
#selector", to be more consistent but still concise.
On Fri, Jun 27, 2025, 3:00 PM Aik-Siong Koh askoh@askoh.com wrote:
Why is UndefinedObject version of "did not understand" so different from
others?
It also inverts the object message paradigm.
Thanks
Aik-Siong Koh
description
"Returns a textual description of the exception (based on the
message instance variable). If message is nil, it returns the
defaultDescription instead."
message ifNil: [ ^ self defaultDescription ].
message lookupClass == UndefinedObject ifTrue: [
^ message selector printString , ' was sent to nil' ].
^ 'Instance of ' , message lookupClass printString
, ' did not understand ' , message selector printString
"nil did not understand #selector" is great.
Similarly, "Instance of " can be replace by "a" as in
"aObject did not understand #selector"
"aReadWriteStream did not understand #selector"
For classes
"PragmaMenuBuilder class did not understand #selector"
Daniel Slomovits wrote:
I think it's because nil is pretty special--this is the equivalent
of a NullPointerException or similar in other languages (even though
in fact nil is an object like any other, it is usually a different
type of semantic error on the part of the programmer than with any
other class). UndefinedObject is also a pretty long class name, so
it's nice to leave that out. But I would be all in favor of making it
"nil did not understand #selector", to be more consistent but still
concise.
On Fri, Jun 27, 2025, 3:00 PM Aik-Siong Koh <askoh@askoh.com
mailto:askoh@askoh.com> wrote:
Why is UndefinedObject version of "did not understand" so
different from
others?
It also inverts the object message paradigm.
Thanks
Aik-Siong Koh
description
"Returns a textual description of the exception (based on the
message instance variable). If message is nil, it returns the
defaultDescription instead."
message ifNil: [ ^ self defaultDescription ].
message lookupClass == UndefinedObject ifTrue: [
^ message selector printString , ' was sent to nil' ].
^ 'Instance of ' , message lookupClass printString
, ' did not understand ' , message selector printString
There is a bit of confusion around the word "understand" here. It is
sensible to think of an object as "understanding" a message or not, but in
fact the selector that tells you whether an object understand a message is
#respondsTo:, while the equivalent on the class which tells you whether
instances of that class understand is the one that's actually called
#canUnderstand:. Other Smalltalk dialects simply say "ReadWriteStream does
not understand #selector", no "a[n]" or "Instance of". (I like the use of
present tense "does not" instead of past-tense "did not", as well, but
that's a much more nitpicky personal preference.)
This is in fact already what you are doing with your class-side example, as
PragmaMenuBuilder class is in fact not the class (that's just
PragmaMenuBuilder), but the class of the class, itself an instance of
Metaclass.
On Fri, Jun 27, 2025 at 4:45 PM Aik-Siong Koh askoh@askoh.com wrote:
"nil did not understand #selector" is great.
Similarly, "Instance of " can be replace by "a" as in
"aObject did not understand #selector"
"aReadWriteStream did not understand #selector"
For classes
"PragmaMenuBuilder class did not understand #selector"
Daniel Slomovits wrote:
I think it's because nil is pretty special--this is the equivalent of a
NullPointerException or similar in other languages (even though in fact nil
is an object like any other, it is usually a different type of semantic
error on the part of the programmer than with any other class).
UndefinedObject is also a pretty long class name, so it's nice to leave
that out. But I would be all in favor of making it "nil did not understand
#selector", to be more consistent but still concise.
On Fri, Jun 27, 2025, 3:00 PM Aik-Siong Koh askoh@askoh.com wrote:
Why is UndefinedObject version of "did not understand" so different from
others?
It also inverts the object message paradigm.
Thanks
Aik-Siong Koh
description
"Returns a textual description of the exception (based on the
message instance variable). If message is nil, it returns the
defaultDescription instead."
message ifNil: [ ^ self defaultDescription ].
message lookupClass == UndefinedObject ifTrue: [
^ message selector printString , ' was sent to nil' ].
^ 'Instance of ' , message lookupClass printString
, ' did not understand ' , message selector printString