Re: PHP 5.1

> 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