On Wednesday 24 April 2002 08:31 pm, Rob Withers wrote:
> This weekend, I hope to continue with the WeakMessageSend we were
> discussing, for the receivers and args.  How does the finalization
> mechanism work?  Will it nil out garbage slots?

Yes. So it's not clear what you should do when you have an argument 
slot that's nil. I guess you could keep flags saying which arg slots 
were supposed to be nil.

That is: if someone makes a WeakMessageSend and passes in an argument 
that is only held onto by the arguments array in the WMS, then it 
will be GC'd and the slot will become nil.

This kind of error will be hard to debug, which is why I'd recommend 
having a bitflag (say) that marks the position of desired nils in the 
args array.

You could disallow sending messages to nil (I can't imagine that such 
messages are very useful). So the receiver could go away and you 
could detect it (and signal a meaningful exception, or just not do 
the call).

Depending on whether you want to be able to change the arguments after 
you create a WMS, you might be able to get away with this:

Object weakSubclass: #WeakMessageSend
	instanceVariableNames: 'selector '
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Kernel-Objects'

and keep the receiver and the arguments in the indexed slots. But 
you'd have to know the number of args at construction time to call 
new: .

If you don't mind using become: you could even change the number of 
arguments. I think. Though I don't know if you can use become: with a 
weak object.

Or you could use a WeakArray to hold onto the arguments and/or 
receiver. That way you could make a new one if someone wanted to 
change the number of arguments.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE