[Cuis-dev] unnecessary punctuation

[Boris Shingarov]

> IMO, it is usually fine to use the same selector with different meanings in
> different classes, its not always bad (IMO) and it makes code nicer to read
> and selectors easier to guess (for a new user).

Hmm.  I think it can lead to a nightmare.  Imagine I want to refactor,
in particular to rename.  So I rename the implementors of the first
meaning.  Now I have to rename in the senders.  How am I supposed to
tell which senders are first-meaning and which are second-meaning?

What if there are 1000 senders?

For example, if I did want (just for the sake of argument) to avoid
collision between Association>>value and BlockClosure>>value, by
renaming BlockClosure>>value to something else, I'd be looking at 406
senders in the base Cuis.  Given the late-bound nature of Smalltalk,
how am I supposed to know where the receiver of #value was meant to
be Association or BlockClosure?  What about the (admittedly unlikely,
but still theoretically possible) execution walkthrough where *both*
are possible?

> But when a subclass down the hierarchy redefines a message with a totally
> different meaning it is wrong

It most definitely is wrong.  I also think it is worth noting that this
has an "opposite direction" so to speak; that is, if we imagine this as
a "developing process unfolding in time", it seems to me that what you
are saying is, "having #+ denote addition in Integer, we better make
sure #+ denotes addition also in SmallInteger".  In that case, I would
also add the other direction: "if we already have SmallInteger>>+ and
it means addition, then we better make sure Integer>>+ also means
addition".

Why am I saying this?  Because in that "other direction", if we already
have BlockClosure>>value, then Object>>value better mean the same thing.

> That’s why it seems to me that its better to keep
> Object as small as possible and perhaps remove Object>>#value.

Or keep Object>>#value and remove the other 5000 (if we are in Pharo).

> I think we
> already talked about this tho, and we didnt remove it, was it because
> dependencies or events rely on it?

Well when we were talking about it over in Slack, I think it was because
Lawvere relies on it.  Wait, how do you encode elements-as-morphisms in
Arrows?