My first impression also was that dependents should not observe the new
object, be it a Model or anything else.

Also Object has some template methods that in the base class do nothing.
Since as Object has no state, it makes sense to me that its postCopy method
should do nothing.

Eliot Miranda <eliot.miranda at gmail.com> schrieb am Fr., 21. Aug. 2020,
21:26:

> Hi Christoph,
>
> On Fri, Aug 21, 2020 at 10:55 AM Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:
>
>> Hi all,
>>
>>
>> please consider the following snippet and its output:
>>
>>
>> o := Object new.
>> o addDependent: 42.
>> o copy dependents. "#()"
>>
>>
>> In my opinion, this behavior is misleading for two reasons:
>>
>> 1. #copy is documented as to "answer another instance just like the
>> receiver." From an abstract view of the object, this should include the
>> object's dependents, too. Afaik, DependentsFields is only an implementation
>> detail, but in common sense, the dependents are just another part of the
>> object.
>>
>
> I disagree.  Dependents are a mechanism for observing an object. They
> allow external objects to register interest in a particular instance.
> Those observers are not interested in observing the state of arbitrary
> copies, but of particular objects being observed.  In the history of
> Smalltalk-80 that I'm aware of from Smalltalk-80 v2 through to VisualWorks
> 7.x, copying did *not* copy dependents.  In fact, in Model, where for
> efficiency, Model>>postCopy did self breakDependents.
>
> Before we go further, imagine inspecting some object.  An
> inspector updates its view of the object being inspected whenever that
> object issues a changed method.  Now let's inspect a copy of that object.
> Wth your implementation both inspectors update whenever either object
> changes state.  This isn't at all what we want.
>
>   Now for the actual bug.  If you look at copy for Model in Squeak, copy
> does *not* break dependents, and hence we get the behaviour you (think you)
> want:
>
>
> (Model new addDependent: Object new; copy) dependents    =>   a
> DependentsArray(an Object)
>
> This is a bad bug, and I only discovered it when I looked for a
> counter-example to your suggestion andfound that Model did (IMO) the
> *wrong* thing.  So if there is a bug, and I think there is, the fix is:
>
> Model>>postCopy
> self breakDependents
>
>
> 2. If you run exactly the same snippet with a Model instead of an
>> Object (which implements dependencies in a different way under the hood),
>> the copied object will contain the original dependencies, still. I think we
>> should unify this undocumented and unintuitive discrepancy. The Model
>> documentation states it features "fast dependents maintenance" so the
>> behavior should be kept, just optimized.
>>
>>
>> How do you think about this?
>>
>> Can we change the Object behavior or could this introduce any
>> unpredictable consequences?
>>
>> And how could we fix it?
>>
>>
>> And what about #shallowCopy? Unfortunately, it is called directly by more
>> than a hundred senders in the Trunk image. Because DependentsFields is an
>> implementation detail, I wonder whether #shallowCopy should copy the
>> dependents as well. Should we move the actual primitive method to
>> something like #primShallowCopy and in #shallowCopy, update DependentsFields
>> after calling the primitive? Or do we rather consider #shallowCopy as a
>> low-level method (similar to #veryDeepCopyWith: as apposed to
>> #veryDeepCopy) and call it a code smell to call #shallowCopy from a
>> far-away place?
>>
>>
>> And LBNL: What should the following snippet output in your opinion?
>>
>>
>> o1 := Object new.
>> o1 addDependent: 42.
>> o2 := o1 shallowCopy.
>> o1 addDependent: 43.
>> o2 dependents asArray.
>>
>>
>> Should it answer: a) #(), b) #(42), or c) #(42 43)? :D
>>
>>
>> I am looking forward to your opinions! :-)
>>
>>
>> Best,
>>
>> Christoph
>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200821/4d8686a9/attachment.html>