> 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