<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Rodney, what if the signatures of overloaded operators is "fixed".<br>That is + can only take two T's and return one T.<br>< can only take two T's and return one boolean.<br><br><br>No implicit conversions.<br> (I do think some conversions are ok, integers to wider integers, but nobody else agrees.)<br>Isn't that much simpler than any other language does it?<br>Are the rules still hard to understand?<br> (And I believe this is still fairly valuable.)<br><br><br>Furthermore, something like, maybe, the operators may only be defined in the interface that declares T?<br>Or maybe, the operators are always available on all types, but you get a link error if they weren't defined?<br><br><br>And of course, you can't define them for builtin types. They are already defined.<br><br><br>And, I realize, there is a question of errors.<br>+ can fail.<br>The interface would have to that they raise exceptions.<br>You could have something like FPU.i3 custom per type to control it. The compiler<br>wouldn't know about this (except maybe for builtin LONGINT).<br><br><br> - Jay<br><br><br>> Date: Sun, 21 Nov 2010 13:52:08 -0600<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] operator overloading?<br>> <br>> I've been around that block too many times with Ada and C++. Programmer-<br>> defined overloading (either operator and/or function name) is a semantic<br>> disaster. It interacts with stuff all over the language, and the complexity<br>> just explodes. I have spent several years of my life having to learn every<br>> in and out and dark corner of overloading and all its fallout in Ada, both<br>> to implement it and to try to help working programmers cope with it. I can<br>> say with complete confidence that Ada would be half the size/complexity<br>> it is, without it.<br>> <br>> Moreover, hard as it is for a compiler writer or language lawyer to understand<br>> it, it is even worse for the everyday programmer. Again, I can testify that<br>> almost nobody (the above types excepted) comes anywhere close to understanding<br>> the rules. They don't even want to try. Their eyes glaze over, and they just<br>> want you to tell them how to code such-and-such so it will compile and call<br>> the function they want it to. For the future, all they want is restrictive<br>> but simple programming guidelines on things to avoid unconditionally, so they<br>> won't keep getting burned again and again.<br>> <br>> C++'s take on overloading is simpler in some respects, more complicated in<br>> others, but overall, quite a bit worse and, I dare say, much poorer-understood<br>> by working programmers.<br>> <br>> The upshot is that the (mis)feature of programmer-defined overloading is mostly<br>> used only in degenerate and trivial ways. This, of course, raises the question<br>> what good is it when: 1) it makes programming more difficult, 2) programmers<br>> avoid most of it anyway, and 3) even so, it results in lots of code that<br>> programmers just barely hope they understand the meaning of what they wrote.<br>> The latter is a *very* big deal in quality of released code. And I didn't even<br>> mention the added difficulty in implementing the language.<br>> <br>> I do realize that function call notation can be a lot harder to read (and write)<br>> than operator notation in a few situations. I've also been around that block more<br>> times than one, in fact quite recently.<br>> <br>> I have many times mused over whether it would be possible to add something that<br>> would give the most important benefits and not be a complete semantic train wreck.<br>> Sometimes I think it could be done a lot better than we have seen, but at best,<br>> it would be a significant semantic complication, even if restricted to operators<br>> only.<br>> <br>> In Modula-3, we have a language whose most distinctive characteristic is an<br>> exceptionally high ratio of useful stuff to complexity. AFAIK, there is no other<br>> language that comes close by this criterion. We need to preserve that.<br>> <br>> Rodney Bates<br>> <br>> <br>> Jay K wrote:<br>> > Is it really so difficult to add operator overloading to the language?<br>> > <br>> > From a user's point of view, I know it is very useful in certain <br>> > situations.<br>> > <br>> > <br>> > - Jay<br>> > <br>> > <br>> > <br>> > <br> </body>
</html>