[squeak-dev] The Trunk: Kernel-fn.1223.mcz

Chris Muller ma.chris.m at gmail.com
Mon Apr 29 19:57:33 UTC 2019

>> Hey Fabio, would you mind consulting your peers a bit more on some of
>> these things prior to trunk?
> Sure, sorry for the lack of explanation.
>> Because I see a problem with "consistency" here.  #postCopy is a no-op
>> if there's nothing to do, not an error.
> SmallIntegers and SmallFoat64 are immediates and cannot be copied.
> This change ensures #postCopy cannot be sent to them, because it does
> not make any sense.
>> In your main #copy entry method, you silently ignore, but here you
>> want to throw an error.  What are you trying to accomplish here?
> I don't quite understand. What do you mean by "main #copy entry
> method"? SmallInteger and SmallFloat64 override #copy to return `self`.

Right.  That's the inconsistency.  In fact, there's inconsistency
along two dimensions, the first being against the behaviors of other
#postCopy's (none of which signal an error), the second being between
the response behavior we implement in #copy to simply ^self.

A lot of objects inherit #copy, and therefore get sent #postCopy.
Canonical objects like the ones you're addressing, as well as Symbol,
should override the *lowest-level method they can*, and nothing more,
to accomplish the necessary requirement(s).  In the case of #deepCopy,
that's #deepCopy, but in the case of #copy, #shallowCopy is all that's
needed, and we should just leave it at that.  From an API-design
perspective, SmallInteger>>#copy is unnecessary.  It just makes extra
methods to see and scroll through in the browser, instead of letting
inheritance do its work.

If this postCopy code you've written will ever execute, it's changed the
behavior of systems which send #copy to a heterogeneous collection of
objects without having to check each one whether its a SmallInteger or
not.  If it won't ever execute, then it's bloat.


More information about the Squeak-dev mailing list