On May 26, 2006, at 4:31 AM, Craig Latta wrote:

> Hi Colin--
>
> > How does Spoon maintain Selector identity across object memories?  
> When
> > a method is transferred from one object memory to another, how  
> are the
> > selectors in its literal frame interned when it arrives? I don't
> > imagine the selectors have UUIDs.... perhaps the selector tables do?
>
> 	There's no need to maintain Selector identity across object  
> memories. The only important thing is that a Selector used in the  
> literal frame of a sending method be the same one used as the  
> method dictionary key for the method to which the sending method  
> refers. The behavior for transferring methods ensures this.

Let me give an example.

Lets say I've got some GIS code, and I overload #at:put:. So 1- 
at:put: refers to the usual meaning for Arrays and Dictionaries,  
while 2-at:put: is my new meaning for plotting locations on maps. My  
GIS module uses both. Let's say that a class implementing 2-at:put:  
gets transferred, and then later, a method that sends 2-at:put:. So  
we've got 2-at:put: going across the wire in 3 places: as a key in a  
method dictionary, in the literal frame of a compiled method, and  
during active imprinting, a request for a missing method implementation.

Somehow, Spoon has to disambiguate between 1-at:put: and 2-at:put: as  
they move across the wire, so that selectors in literal frames  
correspond to the selectors in method dictionaries the same way they  
did in the development image. This is what I mean by "maintain  
Selector identity." How does Spoon accomplish it?

Colin