What you've just suggested there has the makings of a decent proposal in
itself :)
But I think it would inevitably mean that the built-in types would need to
have methods or at least pseudo-methods for special purposes.
Of course, it may that this is a problem which isn't really worth solving
Quoting alan.f...@gmail.com (2018-10-13 15:39:46)
>Unfortunately, no approach is immune to silly mistakes by yours truly
>but, as it's an area where "Effective Go" could offer some pointers, it
>need not be unduly error prone in practice.
Still, some approaches are more error prone th
Thanks for your comments, Ian.
Unfortunately, no approach is immune to silly mistakes by yours truly but,
as it's an area where "Effective Go" could offer some pointers, it need not
be unduly error prone in practice.
The problem with associating operators with named methods is that there
will
Quoting alanfo (2018-10-13 13:26:18)
>Suppose we turn this strategy on its head and instead allow types which
>wouldn't otherwise do so support the ordering operators provided they
>satisfy a simple interface. This interface would have a single method
>which returned a string repr
