Re: Revisiting Userland Operator Overloads

On 08/08/2021 16:39, Larry Garfield wrote:

1) Implementing an interface and stubbing out some methods is a lie. It's a lie the engine won't stop you from telling, but it's still a lie. If you only support addition and division, for instance (add to a collection and split a collection into several), then having a bunch of comparison methods that your object says you support but the program dies as soon as you use it is a lie, and a landmine waiting to happen.

I find it odd, given your other comments, that you keep coming back to collection examples, which seem to me very much in the realm of re-defining the symbols to mean something different in a new domain. If "+" can mean "union" and "/" mean "partition", why not also let "<<" mean "append"? If we're saying we don't want "arbitrary weirdness", then discouraging "add" and "divide" on a collection feels like a feature, not a bug.

2) As Jordan demonstrated, there are many even formally defined situations where some of the operators are explicitly meaningless.

Yes, and as I demonstrated, there are situations where some of the operators are only meaningful for a subset of operands. Saying that a Money object is "Multipliable" would also be "a lie", since multiplying two Money objects together is a logic error, even though multiplying Money by a unit-less number is very useful. Regards, -- Rowan Tommins [IMSoP]