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/097701d4/attachment.html>