[squeak-dev] Bug in #copy?
Christoph.Thiede at student.hpi.uni-potsdam.de
Fri Aug 21 17:55:36 UTC 2020
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.
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! :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev