Ian Denhardt <i...@zenhack.net>:
> I feel like Burak's proposal is falling into the same trap as many others:
> there is a common feeling that operator overloading is a Pandora's box, so
> folks are trying to work around it by solving the problem without providing
> operator overloading. But *the problem itself* is not being able to abstract
> over operators, so this approach is doomed to failure. You just result in a
> clumsy design that can't decide if it's trying to allow operators to be
> abstracted over or not, since the whole point is to allow this, but the
> particulars of the design are motivated by a fear of actually doing so.
>
> I there is a fundamental conflict here. You can express the same concepts
> as with operator overloading if you're willing to wrap the basic types and use
> methods like .Less() in generic code. But I think fundamentally folks have to
> make choice: do we want to be able to write `<` for user defined types, or do
> we want to be able to look at the `<` operator and know for certain that it's
> not calling a method? You can't have both.
Ian has just unpacked my "unwelcome conclusion" very nicely. This is *exactly*
the insight that led me to design "implements".
This is why I confidently predict that nobody will find a simpler way
to approximate contracts than "implements". Ever. (In particular,
Burak's way is, though clever and interesting, not simpler.) Because
"implements" is the dead bare minimum expression of abstracting over
operators; anything else you do to go near that has to be more
complicated and roundabout.
Of course "implements" is not an entire generic system; we need syntax
and semantics for parametric polymorphism and parametric types, too.
But it's a *good thing* that "implements" can be described without any
reference to these concerns; it means we have *orthogonality*.
I would go further than that and say any proposal that has to specify all
three extensions (contracts, parametric polymorphism, parametric types)
at once in order for any of it to work is too complex, fails orthogonality
forever, and should be regarded with deep suspicion that it is overcommitting
the language in a wrong direction.
The "implements" proposal adds just one keyword. *One,* and the syntax
is trivial. That's not just parsimony on the surface, it's a
fundamental clue that we have found the simplest way possible to
express what it gives us access to.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
