Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!portc02.blue.aol.com!howland.erols.net!blackbush.xlink.net!ins.net!heeg.de!hmm
From: hmm@heeg.de (Hans-Martin Mosner)
Subject: Re: New Smalltalk root (was Re: X3J20 and isNil (was Re: Conclusion: etc..))
Message-ID: <E17nqn.7Az@heeg.de>
Sender: uucp@heeg.de
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG
X-Newsreader: TIN [version 1.2 PL2]
References: <3285F093.339F@kommsrv.rz.unibw-muenchen.de> <3289BB7C.6839@kommsrv.rz.unibw-muenchen.de> <328FED74.7BA8@best.com> <329107FF.7CB0@concentric.net> <3290F4D6.1879@best.com> <32910457.708B@pobox.com> <3291F557.4415@best.com> <32920EA8.7B71@iconcomp.com> <changi0.9m.2D2C4x$07U@craftedsmalltalk.com>
Date: Thu, 21 Nov 1996 08:03:58 GMT
Lines: 51

traymond@pcix.com wrote:
: In <32920EA8.7B71@iconcomp.com>, Bill Gooch <bill@iconcomp.com> writes:

: >Note that proxies and such are in fact *not* "undefined objects,"
: >and that subclassing UndefinedObject is neither necessary, nor
: >a particularly good choice of means to implement them.  It's merely
: >a convenience.  If instead one creates Proxy and related classes 
: >in a separate subtree descending from Object, then the question of 
: >(ab)using isNil/notNil becomes moot.

Note that the general mechanism for implementing Proxies and Stubs
is not subclassing from UndefinedObject, but subclassing from nil.
Proxies and Stubs stand in for some other object, and so they need
to intercept messages to reroute them to the object they stand for.
That's a completely different thing.
Nil always stands for itself. It's just the default value
of uninitialized instance variables.
Subclassing from UndefinedObject is never necessary or reasonable.
In my opinion, UndefinedObject should explicitly disallow subclassing.

: >  It's a tad more work (not much, 
: >since - in VW, anyway - you can always copy and modify UndefinedObject 
: >by filing out, editing, and filing in), but better style.  Had someone 
: >anticipated this need, it might have been considered worthwhile to put 
: >an abstract class between Object and UndefinedObject, which could be 
: >the common ancestor for all classes of nils, proxies and such. 

: I think a better approach would be to have a single rooted
: hierarchy with the root having a minimal set of methods.
: Both, Object and UndefinedObject would be subclasses of
: this minimally defined class.  Proxy classes would also
: be immediate subclasses of this new root.  Furthermore,
: it would be very highly recommended not to add methods
: to the root, as is done with Object.

That might be reasonable, for example to put the object enumeration
primitives and such into this new superclass of Object and everything.
However, making UndefinedObject a subclass of this new superclass
instead of Object does not make much sense. If you need to discriminate
between, for example, Foos and non-Foos, you would simply implement
#isFoo in class Foo and in class Object, returning true in the first
case and false in the second case. Then nil will answer false in
response to the method #isFoo.

Hans-Martin

--
+--- Hans-Martin Mosner ---- Senior Smalltalk Guru :-) ---+
| These opinions are entirely ficticious.  Any similarity |
| to real opinions is purely coincidental and unintended. |
+--- <hmm@heeg.de> ------ URL:http://www.heeg.de/~hmm/ ---+
