#swappingBecome: and events

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

#swappingBecome: and events

Dmitry Zamotkin-4
Hello,

A method #swappingBecome: (#become: as well) does not swap events of the
receiver and the argument after applying. Is this by design or a bug? Here
is a simple example:

a := Object new.
b := Object new.
b when: #isNil sendTo: a.
b trigger: #isNil. "false"

c := Object new.
c swappingBecome: b.
c trigger: #isNil. "nil"
b trigger: #isNil. "false"

--
Dmitry Zamotkin


Reply | Threaded
Open this post in threaded view
|

Re: #swappingBecome: and events

Dmitry Zamotkin-4
Hello,

> A method #swappingBecome: (#become: as well) does not swap events of
> the receiver and the argument after applying. Is this by design or a
> bug?

I've added a new method to resolve this problem (?):

"--"
Object>>becomeWithEvents: anObject
    | receiverEvents argumentEvents |

    receiverEvents := self getEvents.
    argumentEvents := anObject getEvents.

    self become: anObject.

    anObject setEvents: receiverEvents.
    self setEvents: argumentEvents.
"--"

--
Dmitry Zamotkin


Reply | Threaded
Open this post in threaded view
|

Re: #swappingBecome: and events

Blair McGlashan
Dmitry

You wrote in message news:[hidden email]...

> Hello,
>
> > A method #swappingBecome: (#become: as well) does not swap events of
> > the receiver and the argument after applying. Is this by design or a
> > bug?
>
> I've added a new method to resolve this problem (?):
>
> Object>>becomeWithEvents: anObject
>...

Sorry, I had intended to reply to your initial post but it slipped my mind.
The behaviour is by design, for better or worse, and is compatible with the
behaviour of St-80 with respect to old dependency mechanism, i.e. the events
are registered against the object identity, and are not considered part of
its state. Since become: swaps the "body" of the object, and not the
identity, the events remain associated with the identity against which they
were originally registered. This means that, for example, should I register
some events against a hypothetical proxy object, then when/if that proxy is
exchanged for the real value, the events are now registered against that
value. This makes sense for a transparent proxy, although there may be other
use-cases where the opposite behaviour is desirable.

One could make arguments that it should work either way, but it should be
consistent and in that respect there is a bug in Dolphin in that objects
which provide their own event storage (i.e. they store the events collection
as part of their state) behave differently.

Regards

Blair