On Monday 16 June 2003 01:18 am, Chris Burkert wrote:
> Ned Konz wrote:
> > On Sunday 15 June 2003 05:19 pm, Chris Burkert wrote:
>
> [snip]
>
> > The problem is that the WeakMessageSends we're using (well, my
> > name is all over this, so I guess I'm responsible) hold on to
> > their receiver *and* their arguments weakly.
> >
> > So "Color black" works, but "Color black copy" wouldn't (same
> > with "Color black alpha: 0.3" or any other transient object.)
> >
> > We've discussed this at length in the past (like back on February
> > 9) and never really did anything about it.
>
> Could we now do something about it? I don't wanna override the
> events code and the only difficult part to change it is to agree
> on the names for the messages I think.

Well, I don't see this as something that's crying out for a change. We 
figured that we'd get some more experience with the system and see if 
it was a problem.

We took the most conservative possible approach (making absolutely 
sure that the event system was not going to hold on to *anything*). 
It is always possible to find another object to hang on to receivers 
and/or arguments that you want to use in the event system.

To hold on to a receiver, we have classes and the worlds and the 
projects.

To hold on to arguments, we have the receivers and other objects. That 
is, in your example, the object that's specifying the colors can 
either hang on to them in itself, or if it's transient, can put them 
on its class side, or in Preferences (if it's really a color 
preference). Looking at the code, this is something that should 
either be in WorldMenu, or in the instances, or in a color 
Preference.

For instance, just adding a "colors" instance variable to WorldMenu 
would hold them securely. After all, the lifetime of the colors 
doesn't need to be any longer than the lifetime of the menu itself!

Though if changes to the event system were needed, here's a few 
potential changes that could be made:

1. make it so *all* the arguments can be strongly held (i.e. just 
replace arguments with a regular Array)

This could look like:

on: event send: #sel to: someObject withStrongArguments: anArray

2. Make it so the receiver can be strongly held (imagine a regular 
MessageSend with a WeakArray for its arguments)

This could look like:

on: event send: #sel toStrongReceiver: someObject withArguments: 
anArray

3. Make it so *some* of the arguments can be strongly held

It won't work too well to have an after-the-fact 
"strengthenArguments:" message, as the arguments could already have 
gotten GC'd, and this would be annoying to track down.

4. Make a more general way to maintain strong references to objects

I'm reluctant to add this, as it would involve a global collection of 
objects that could be an annoying source of uncollected garbage.

I'm not sure about the message names above.

Plus, I need to at least comment WeakMessageSend and the event 
registration.

> > For now, just have some object hold on to the colors and it
> > should work fine.
>
> Ok, thanks a lot Ned!
>
> Regards
>             Chris Burkert

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