prototype multiple dispatch creates uncollectable garbage?

[Brian T. Rice]

James McCartney wrote:

> This is a post I made on the self-list which I am reposting here with a 
> more attention getting subject line.
> I am curious what the solution is, if there is one. I just joined the 
> list so perhaps this has been discussed. The archives don't appear to be 
> searchable.

These last few days, I am really busy moving between apartments, and I 
had written a reply but lost it. For now, I will answer that yes this 
does seem to be a current problem, but, no, I can't figure out an actual 
realistic use-case for multi-methods applied at least partly to 
non-well-known (not reachable by name from the lobby) objects. We can 
handle method replacements, but disappearing roles are another issue. 
Note that re-loading code in principle should allow in-place library 
updating, not even having to swap objects, so there is a limit to the 
range of cases where it's needed.

Probably the solution will have to involve a type of system-update 
notification system, kind of a feature which could be applied to have 
the effect of finalizers, as an example. Basically we'd need to trigger 
events when an object's map's roles are removed or otherwise 
invalidated. The problem is then that the system has to correctly 
identify which signature applies to the method. In general, method 
removal is tricky because there may be derived maps and so forth which 
also have the same signature. So there is a deficiency or gap in the 
things that the naive PMD configuration, but we're working on it. One 
factor that allows us not to address it is that our images can be built 
up rather easily, so we haven't been too concerned with removal yet.

-Brian

> On Aug 31, 2004, at 5:45 PM, Jecel Assumpcao Jr wrote:
> 
>> Or even
>> better, see the Prototype Multiple Dispatch in Slate:
>>
>> http://tunes.org/~eihrul/pmd.pdf
>> http://tunes.org/~eihrul/talk.pdf
>>
>> and
>>
>> http://slate.tunes.org/
>>
>> They currently use a very Self-like inheritance model, but plan to move
>> in a different direction.
> 
> One problem with the prototype multiple dispatch scheme, if I
> understand it correctly, is that methods become uncollectable garbage
> unless ALL of their specialized arguments are collectable. This is a
> problem if you are multiple dispatching on arguments that live forever
> like true, false and nil. Because roles are stored in each object that
> participates in a method dispatch, once you define a method on an
> object, that method lives as long as any of the argument objects lives.
> This would make it tricky to create ephemeral objects with unique
> behavior that use multiple dispatch.
> 
> Hopefully one of the Slate folks can speak to this..
> ---end of original post---
> 
> for example see page 16 of talk.pdf.
> The "encounter" methods cannot be garbage collected until both of their 
> referrers can be. In the case given it would not be a problem since 
> these are traits objects and presumably live for the life of the 
> program, but it would be a problem for a temporary object with unique 
> behavior.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: water.vcf
Type: text/x-vcard
Size: 208 bytes
Desc: not available
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20040903/3667e59d/attachment.vcf>