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.
Best, Chris