[self-interest] Re: data structures

David Ungar David.Ungar at Eng.Sun.COM
Fri Jun 11 17:59:26 UTC 1999

Let me try two ways to see this:

1. Objects are supposed to be things that have behavior appropriate 
to their context.
     But nil has no behavior--you are reduced to asking for its identity.
     Nil is used for at least two cases: a container is uninitialized, 
or an optional bit
     of information is absent. In an object-oriented system (IMHO) one 
would just send messages
     to the object and it would do the right thing. So it is better to 
use more specific objects instead of nil.

2. When moving from functional to object-oriented programming, we see 
if statements
     being replaced by polymorphic message passing. The right thing 
happens because
     the receiver finds the right behavior. But programming with nil 
invariably involves
     statements like "if (x == NULL)".

Hope this helps,

- Dave

At 9:09 AM -0300 6/11/99, Douglas Atique wrote:
>Huh? I didn't understand... See my comments below.
>David.Ungar at Eng.Sun.COM wrote:
>> Amen!
>> When designing Self
>> I came to believe (and still do) that the idea of 'nil' is not
>> object-oriented at all.
>Why isn't it object-oriented? I've always understood nil (or NULL, or null) as
>"nothing", "no object". If I say "What object is pointed to by this 
>slot?" and the
>answer is "no one" then it seems right that nil is there. I thought nil was
>necessary to have some value or some object to indicate this 
>absence. In C++, for
>instance, the conceptual nil object (which is at adress 0, aliased 
>NULL, right?)
>exists as some object whose address is 0x00000000. If the implementation cares
>about it (and I think they all must care) there should be no real object or
>variable at address 0, so that no real object can have the same 
>address as NULL.
>Then, why not think the memory at address 0 contains an object? I am 
>used to fake
>to myself that there is a system-defined object there named NULL, 
>whose address is
>0 (but could be any other address) and it seems conceptually clean. 
>Many algorithms
>I have implemented take into account that a pointer containing NULL refers to
>"nothing", meaning that none of the objects that interest the 
>algorithm is there.
>If we come to the implementation side (pardon me again :-) we can't avoid to
>consider that every reference to an object is implemented as a 
>pointer, that is, as
>a memory location whose value is an address. So how do you say "This 
>slot doesn't
>point to anything" ? Leave it with a random value? This seems 
>dangerous, as you can
>always coincidently refer to an existing object, or to garbage 
>(which can be part
>of an object's memory). Don't we need the concept of "no object"? 
>Could you please
>explain this again?
>> It is just a holdover from Lisp via Smalltalk.
>> If I had to do it all over again, there would be no nil in Self.
>> (So why? Because 'nil' is the same no matter what kind of object
>> isn't there. This leads to code such as:
>> nil = foo ifFalse: [
>>     <do something with foo>
>> ]
>> If instead, you make a special object that respects the right
>> protocol you could write
>> foo doSomething
>> or
>> foo doSomethingIfNotInitialized: [...]
> > - Dave

     David Ungar
     Sun Microsystems Laboratories
     (650) 336-2618


eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications

More information about the Self-interest mailing list