Re: PHP 5.1

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