prototype multiple dispatch creates uncollectable garbage?
Brian T. Rice
water at tunes.org
Fri Sep 3 11:34:02 PDT 2004
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 : /archives/slate/attachments/20040903/3667e59d/water.vcf
More information about the Slate
mailing list