Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14576
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <030301c50a15$024897b0$a900000a@adstate.local>
To: <internals@lists.php.net>
References: <5.1.0.14.2.20050201111730.0299da70@localhost> <ctsskd$cl8$1@sea.gmane.org> <Pine.LNX.4.58.0502031204000.6513@shire.zend.office>
Date: Thu, 3 Feb 2005 18:22:59 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.1
From: tslettebo@broadpark.no (=?iso-8859-1?Q?Terje_Sletteb=F8?=)

> 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