¿Tiene sentido usar nil?

En el último post, una de las preguntas que dejé pendiente era si bajo las condiciones de modelado comentadas tenía sentido utilizar "nil" (o "null" en otros lenguajes... aunque "nil" y "null" no son lo mismo[1]), si los objetos debían o no tener variables de instancia referenciando a "nil".
La realidad es que si aplicamos los principios que comenté en el post pasado, ningún objeto debería tener variables de instancia con "nil" (salvo por cuestiones implementativas como las que comento más abajo). Si al momento de crear objetos, a estos se le indica cuales son todos sus colaboradores internos, no debería existir ninguno de ellos referenciando a "nil".
Imaginense las ventajas que esto tiene! El objeto "nil" es uno de los más "dañinos" desde el punto de vista de "programación correcta o segura", puesto que su existencia implica que en algún momento se le deberá preguntar si es él (el famoso mensaje isNil o ==null en otros lenguajes), lo cual deriva en un ifTrue: (o if...) y por lo tanto en un posible foco de error y conflicto (error por olvidarse de hacer dicha pregunta, conflicto en el caso de la evolución del modelo, etc.)
Con esto no quiero decir que el objeto "nil" no debería existir o que no se lo debería utilizar, "nil" debe existir por lo que representa, "la nada", pero cuanto menos utilizado sea, mejor.
Siguiendo los consejos que publiqué en el post anterior, el uso de "nil" por lo tanto se disminuye al máximo y por ende también los errores que el uso del mismo induce.
El único motivo que encontré hasta ahora para utilizar "nil" como variable de instancia en un objeto, es para aquellas variables que "cachean" algún objeto y por lo tanto se pueden inicializar de manera lazy. Pero justamente por ser una cache o inicializarse de manera lazy, son colaboradores que solo debe conocer el objeto que los referencia y por lo tanto nunca otro objeto podrá pasarlo en el momento de la creación.
Por otro lado, les comento que en ambientes de objetos transaccionales como GemStone, tener variables que se inicialicen de manera lazy no es tan trivial puesto que al momento de comitiar una transacción se pueden generar conflictos de write-write. Por ejemplo, si desde dos transacciones distintas se le envía el mensaje que inicializa dicha variable al mismo objeto, aquella que commitee segunda tendrá el conflicto que comenté puesto que la primera ya habrá "escrito" dicha variable de instancia.

[1] "nil" en Smalltalk es un objeto, instancia de UndefinedObject y por lo tanto puede recibir mensajes y también se lo puede modificar. null en Java o .Net no es un objeto, es una construcción sintáctica y por lo tanto no posee la misma riqueza lingüística que "nil". ¿Qué significa "mayor riqueza lingüística?, les dejo un ejemplo para que lo deduzcan por su cuenta: (Este ejemplo fue una gran idea de Luciano!)
En un framework que usamos es necesario crear un diccionario cuyos valores pueden ser "nil" o no. Por ejemplo:

ClassXXX>>insertValuesFrom: aCuenta

 ^Dictionary new
   at: 'sucursal' put: (aCuenta sucursal isNil ifTrue: [ nil ] ifFalse: [ aCuenta sucursal objectID ]);
   at: 'calificacionCuenta'put: (aCuenta calificacion isNil ifTrue: [ nil ] ifFalse: [ aCuenta calificacion codigo ]);
   ...
   yourself.

Como pueden ver, este framework no sigue los consejos que di en el post anterior y por ello es necesario verificar si 'sucursal' es "nil" para enviarle el mensaje #objectID en caso de no serlo. Lo mismo sucede con 'calificacion'.
Como podrán darse cuenta, escribir código de esta manera es error prone (propenso a error), tedioso, molesto, cansador, poco inspirador y poco divertido (se lleva todas las malas). La gran idea de Luciano fue darse cuenta que "nil" es un objeto y por lo tanto puede saber responder los mensaje #objectID y #codigo de tal manera que devuelvan self!. Por lo tanto implementando los siguientes métodos en UndefinedObject:

UndefinedObject>>objectID
    ^self

UndefinedObject>>codigo
    ^self

no es más necesario hacer los chequeos anteriores!. Transcribo lo que Luciano escribió:
"De esa manera el código del ejemplo anterior se puede escribir así, que es mucho más claro y se eliminan todos los isNil ifTrue:[] ifFalse:[] que entorpecen la lectura:"

ClassXXX>>insertValuesFrom: aCuenta

 ^Dictionary new
    at: 'sucursal' put: aCuenta sucursal objectID;
    at: 'calificacionCuenta' put: aCuenta calificacion codigo;
    ...
    yourself

¿Se ve a simple vista no?... Esto es riqueza lingüística, es la posibilidad de modificar el lenguaje para cumplir con objetivos que no estaban pensados en primera instancia, es poder hacer evolucionar un lenguaje de la misma manera que evoluciona un lenguaje natural. De más está decir que con Java, .Net o C++, etc, esta solución no es factible puesto que "null" no es un objeto.
Se puede discutir si desde el punto de vista conceptual es correcto implementar estos mensajes en UndefinedObject... seguramente nuestra conclusión será que no, pero que ayuda, no perjudica y es muy práctico, no quedan dudas.
Así que, me saco el sombreo: Grande Lucho!