C++ is not PHP and the sooner you realize this the better it will be. Adding operator overloading will add yet another layer of "magic" that will confuse users, who for the most part have demonstrated that they are not ready for such features. If anything it'll only over complicate applications making them neigh impossible to debug and require all sorts of hackery inside the language itself to support this functionality.

Ilia

Terje Slettebø wrote:
SB>> patch [1] by Johannes Schl?ter that has been floating around for a
SB>> while?

1. I personally don't think operator overloading is a good idea. It
doesn't add you anything you couldn't do without it the same way - it's
pure syntax sugar.


As someone said, "Syntactic sugar matters, or we'd all be writing assembly
code." :)

Besides, it's not "just" syntactic sugar: See my other posts in this thread,
but briefly, they enable "generic code" - code that may be used by both
built-in and user-defined types, without knowing or caring which is which.
That is indeed powerful, and most of the advances in later years in C++ has
come in the area of generic programming (where templates are used for this,
since types are checked at compile-time).


And it really ruins the readability of the code - go
figure what $i++ means now, in absence of any type delcarations.


If it's sensibly implemented, it should increment $i (whatever that is), and
return the previous value.

This is no more confusing than "increment_and_return($i)", where you may
also need to look at the function definition. I find the first version much
clearer, though.


2. The referenced patch raises doubts - why it allows to override / but
not %, for example? What with all other operators?


I agree that if operator overloading was added, it should be available for
all operators where it makes sense.


Why add would work as
$foo + 1, but 1 + $foo won't?


Both would work if we allow operator overloading on free functions. But that
may be too radical for some people, it seems. Just to drive the point home:
Operator (and function) overloading is not an OO feature. However, it's
often found in OO languages, and complements OO well. It's a different kind
of polymorphism.


Will + be non-commutative operation from now on?


There shoudn't be a need for that. We should try to avoid such surprises.


What with assign-ops - it would leak memory in this case?


Why would it do that?

Regards,

Terje


-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to