Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 03 Feb 2005 20:31:09 +0100
To: internals@lists.php.net
Message-ID: <011701c50a26$e9dc6fa0$0300000a@pc>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
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>
	<Pine.LNX.4.58.0502031940490.7784@shire.zend.office>
Subject: Re: [PHP-DEV] PHP 5.1
From: tslettebo@broadpark.no (=?iso-8859-1?Q?Terje_Sletteb=F8?=)

> 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.

It depends on how you define "complexity". Are the following two lines
equally complex to you:

1) $result=$c1.multiply($c2).divide($c1.add($c2));

2) $result=($c1 * $c2) / ($c1 + $c2);

They sure aren't to me. Moreover, they are not the same: operator
overloading enable you to use infix notation, whereas functions use prefix,
only.

> The
> latter is syntax sugar. It is important, but not at the price of making
> code harder to read

If it makes the code harder to read, it's not much of "syntactic sugar", is
it? I can't see why operator overloading should make it harder to read. The
only thing I can think of is that, given that there's no type declarations
in PHP, it may be hard to know, looking at a line, what the type of the
variable is. However, in a properly written program, the actual type may not
be that important. Take for example:

$sum = $money1 + $money2;

Whether or not the variables are built-ins or from a money/currency class,
should matter little to your understanding of this code.

> or language slower to work.

Why would it become slower. As you say, the notation is essentially
"syntactic sugar" for a function call, and should be equally fast.

> 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.

What if you want to add two variables?

> 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

Statically typed, yes.

>, so you need to jump trhough various hoops to make it work in
> non-typed way, while preserving it's typedness benefits.

Yes, if you want to use C++ in a typeless/dynamically typed way, you need to
use things like templates, or a variant type. However, since those are
available, you get the benefits of something similar to type inference, and
also static type checking.

> PHP works differently - you don't have benefits and need no hoops.

You don't have benefits of what? (Should "don't" have been omitted?)

> 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.

Oh, well. Programming by guesswork is always hard. A point with programming
languages is that once you've learned them, and their abstractions, it makes
it easier for you to program. Operator overloading is no different.

> 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.

Yes, you'd need function overloading (we already have type hints, which
could be used for the overload resolution).

> Even if you could - how many operator+'s
> you are willing to write? For all type combinations?

That depends on what you want. I can't see how this question is different
from "How many member functions (like add()) are you willing to write?"?

> Or what is supposed
> to happen if + called for type combination that you don't have an operator
> for?

An error, like today.

> 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.

Yes, overloading is a form of polymorphism. Depending on the type of the
arguments, different functions are called. This is analogous to
inheritance-based polymorphism (virtual functions). See
http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf for a
good treatment of the various kinds of polymorphisms there are (even if the
article is rather mathematical/technical).

> 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.

I beg to differ. Operator overloading allows you to write what essentially
are domain-specific languages (DSLs) in the language itself. For example
Boost.Spirit allows you to write a parser, by expressing the rules in
near-EBNF form, directly in the code!
(http://www.boost.org/libs/spirit/doc/introduction.html) Do _that_ in PHP.

Regards,

Terje