Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14608
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 04 Feb 2005 00:08:35 +0100
To: internals@lists.php.net
Message-ID: <04e901c50a45$49fd85e0$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.0502031101520.12205@localhost>
	<ctste1$f8p$1@sea.gmane.org> <Pine.LNX.4.58.0502031121250.12205@localhost>
	<42020015.5090209@cschneid.com> <02d901c50a0c$b2c0c3f0$a900000a@adstate.local>
	<Pine.LNX.4.58.0502031829350.7648@shire.zend.office>
	<00bc01c50a1f$c000a9a0$0300000a@pc>
	<Pine.LNX.4.58.0502032118430.7966@shire.zend.office>
Subject: Re: [PHP-DEV] PHP 5.1 - operator overloading
From: tslettebo@broadpark.no (=?iso-8859-1?Q?Terje_Sletteb=F8?=)

> From: "Stanislav Malyshev" <stas@zend.com>

> TS>>When you say "typeless", i think you mean "not statically typed".
>
> Not only, but in this case it is the main trait I meant.

...Because PHP has types, so I felt it was a misnomer to call it "typeless".

> TS>>through this discussion elsewhere - a variable will at any one time
have a
> TS>>well-defined type (or unset), which you may overload on, so the
language is
>
> That's the whole point - in PHP there's no mechanism you could overload
> function based on the types of their parameters, neither statically nor
> dynamically. To add this thing would be a very major change and will open
> galactic-size can of worms (think "implicit conversions", "converting
> constructors", "multiple inheritance", etc.).

No, you don't have to go that far. For starters, one could allow function
(and possibly operator) overloading, based on type hints. The following is
legal PHP5:

function something(SomeClass $value) { ... }

We could make the signature (currently only the name) extend to include the
parameters, as well, so we could allow the following, without errors about
duplicate definition:

function something(AnotherClass $value) { ... }

That's it. That's all you need for function overloading. You can safely keep
the lid on that can of worms of yours. :) If we were to extend this, I'm
sure we'd find a way to deal with any "worms".

> And this would seriously complicate function call logic

It would increase the complexity somewhat, since you have to perform
overload resolution. However, how much on an impact this would have on
execution speed remains to be seen.

> - which is very bad, because, unlike
> statically-typed language, we can not offload this complexity to one-time
> compile stage.

Right.

> TS>>Yes, variables are dynamically typed, but when you call a function,
you
> TS>>typically have an idea of what its type is. Otherwise, the "type
hints" for
> TS>>PHP 5 would be pointless! By your argument.
>
> Type hints check if the argument passed to function is of the right type.
> They don't make PHP call different functions on different argument types.

I know. My point was that, as we have type hints, we have a way to
differentiate functions, since they may now both have variable types, and
number of parameters.

> TS>>> - except for select things like
> TS>>> complex and matrices (and maybe two more things like this) I don't
see any
> TS>>> value in having, say, + overloaded. Using good old methods will
never fail
> TS>>> you.
> TS>>
> TS>>Neither will assembly code.
>
> What is with that assembly code that you keep mentioning it?

It was a reaction to the oft-mentioned argument that essentially says: "We
don't need more advanced features." I got that feeling when you said "Using
good old methods will never fail you.". However, I may have misread you. If
taken to the limit, you don't need more than ones and zeroes to program, but
it sure makes it easier to have higher levels of abstraction. Anyway, it
seems we agree on that.

> Assembly code
> is entirely irrelevant to the discussion, since, as I already explained
> once, difference between assebmly code and higher-level programming
> languages in in complexity incapsulation, while difference between
> operator overloading and using method is purely syntactical - operator
> overloading can be translated one-to-one to method calls without exposing
> any complexity, while translating method call to assemly exposes a lot of
> complexity.

I've replied to this in the reply to that posting, so I won't go into it
here.

Regards,

Terje