Posted by
Blair McGlashan-3 on
Jan 13, 2005; 11:10am
URL: https://forum.world.st/become-and-oneWayBecome-tp3372645p3372659.html
"Esteban A. Maringolo" <
[hidden email]> wrote in message
news:41e57eae$
[hidden email]...
> Blair McGlashan escribió:
>> #oneWayBecome: loses the identity of one object (the receiver).
>
> That wouldn't be a problem, indeed i want to loose that object.
> Because it will be used only once, once a message has been send to it, it
> will transform (become) into another object or to nil*.
>
> *It will lookup in the cache (if is loaded), in the external space
> (whatever) and if it doesn't exists in any of those, will become nil (it
> really doesn't exists externally)
You could use #become: for the newly created objects you load from the
external space - these won't have any existing references, so a swapping
become will be fine as well as very fast. However, when you encounter a
second stub referencing an existing object you can't swap out that second
stub with become, because that would break the references created when the
first stub was swapped. #oneWayBecome: would work, but it is relatively very
slow.
You could change your design so that you can always use #become:.
Essentially you have to avoid creating multiple stubs for the same external
object. This usually involves maintaining tables of both stubs and loaded
objects so that you can make sure you share the same stub when creating a
stub, or that instead of creating a stub you use a loaded object when
already available. These tables are often needed anyway in order to manage
updating external data with changes made to an object while loaded, etc. Of
course it is necessary to think quite hard about the interaction of #become:
with your tables (usually implemented as hashed collections). As Chris says,
approach this design problem when sober :-).
Regards
Blair