Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14578
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 3 Feb 2005 19:48:34 +0200 (IST)
To: =?iso-8859-1?Q?Terje_Sletteb=F8?= <tslettebo@broadpark.no>
cc: internals@lists.php.net
In-Reply-To: <030301c50a15$024897b0$a900000a@adstate.local>
Message-ID: <Pine.LNX.4.58.0502031940490.7784@shire.zend.office>
References: <5.1.0.14.2.20050201111730.0299da70@localhost> <ctsskd$cl8$1@sea.gmane.org>
	<Pine.LNX.4.58.0502031204000.6513@shire.zend.office>
	<030301c50a15$024897b0$a900000a@adstate.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] PHP 5.1
From: stas@zend.com (Stanislav Malyshev)

TS>>As someone said, "Syntactic sugar matters, or we'd all be writing assembly
TS>>code." :)
                                                                                                              
Someone was wrong. There are syntax constructs that allow to reduce
complexity of the code, and there are constructs that make the code have
the same complexity but look prettier to the eyes of the writer. The
latter is syntax sugar. It is important, but not at the price of making
code harder to read or language slower to work.
                                                                                                              
TS>>Besides, it's not "just" syntactic sugar: See my other posts in this thread,
TS>>but briefly, they enable "generic code" - code that may be used by both
TS>>built-in and user-defined types, without knowing or caring which is which.
                                                                                                              
I don't see how using $a + 1 is better than using $a->add(1) in this
regard.
                                                                                                              
TS>>That is indeed powerful, and most of the advances in later years in C++ has
TS>>come in the area of generic programming (where templates are used for this,
TS>>since types are checked at compile-time).
                                                                                                              
C++ is typed, so you need to jump trhough various hoops to make it work in 
non-typed way, while preserving it's typedness benefits. PHP works 
differently - you don't have benefits and need no hoops.

TS>>This is no more confusing than "increment_and_return($i)", where you may
TS>>also need to look at the function definition. I find the first version much
TS>>clearer, though.

Well, I guess it's the matter of personal taste. For me, the second is 
the clear winner - you can name function after what it actually does and 
not hope that everybody knows ++ makes an iterator go to the next element.

TS>>Both would work if we allow operator overloading on free functions. But that

It can't be done without making PHP strict-typed - you coldn't really 
distinguish which function is to be called, and you couldn't distinguish 
between functions with same name. Even if you could - how many operator+'s 
you are willing to write? For all type combinations? Or what is supposed 
to happen if + called for type combination that you don't have an operator 
for?

TS>>Operator (and function) overloading is not an OO feature. However, it's
TS>>often found in OO languages, and complements OO well. It's a different kind
TS>>of polymorphism.

It's no kind of polymorphism at all. It just an infix form of writing a 
method instead of prefix form, with additional problem that it is confused 
with plain old arithmetics. I see no value at all in this except for "cool 
toy" value - which is not enough to add such a serious change in the 
language. 

-- 
Stanislav Malyshev, Zend Products Engineer   
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115