One thing we discussed at some length in VisualWorks is a polymorphic
solution for empty slots and "expired" weak references.  In Squeak a
WeakArray's references to reclaimed objects are replaced with nil. In
VisualWorks they are replaced with 0.  Replacing with 0 allows a weak
collection to identify the references just dropped.  A typical weak
collection will be finalized and in its finalization code will scan for 0's
and process corresponding entries for those indices held off to the side
(e.g. finalizable copies).  As each 0 is encountered it will be replaced
with nil.
THis obviously poses a problem for e.g. hashed collections as these can
either no longer contain 0 or must be made thread-safe and have the
finlaization code effectively atomically set all 0's to nil.  But the
thread-safe solution works only for uses less than the finalization
process's priority.  The sketch solution we came up with is to introduce two
singletons, unbound and tombstone which both answer true to isUnbound and
all other objects answer false.  tombstone answers true to isTombstone and
all other objects answer false. Expired weak references are overwritten with
tombstone and hashed collections check for an unbound slot with isUnbound
and an expired reference with isTombstone.  This has support code in the VM
but has yet to be implemented in the image.  The VM's tombstone remains set
to 0.

Hopefully this bites fewer users than nil as an unbound marker but there
will still be system contexts where unbound is a value that needs to be
dealt with (SystemTracer et al).  So the catch is that one has introduced
more complexity with its own attendant problems.



On Sun, Aug 10, 2008 at 8:16 AM, Louis LaBrunda
<Lou at keystone-software.com>wrote:

> Hi Igor,
>
> How about creating a new class called #MetaUndefinedObject or #MetaNil.
>  Stick
> it between #Object and #UndefinedObject.  By definition it would never be
> used
> as an object, it would only be used as a filler for collections like #Set,
> indicating that no "real" object is present.
>
> This would allow nil to be used in sets and elsewhere and allow it to be
> placed
> in a set from a database row where a column is null without changing other
> code.
>
> This would not solve the recursive collection problem but that could be
> solved
> at it source.
>
> Lou
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080810/b8c17eee/attachment.htm