Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48028
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.117 as permitted sender)
Message-ID: <4BCE44B8.6060600@zend.com>
Date: Tue, 20 Apr 2010 17:20:08 -0700
Organization: Zend Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Adi Nita <adi.nita@gmail.com>
CC: internals@lists.php.net
References: <t2y294a23a11004200739v6b3e18f1z52abfa89db643a09@mail.gmail.com>
In-Reply-To: <t2y294a23a11004200739v6b3e18f1z52abfa89db643a09@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] A critique of PHP 6
From: stas@zend.com (Stanislav Malyshev)

Hi!

> 1. SYSTEM NAMESPACES. There are many PHP built-in functions that act on
> certain groups of entities. The best examples are the *array_** and
> *str* *functions.
> There are many of them, and it gets really cumbersome to repeat the same
> prefix for each and every one. This is clearly a reminiscence of original

Come on. Is it really that hard to write strlen? Or array_merge? Would 
it be better if they were len (of what?) and merge (what?)? I don't 
think so.

> procedural-style PHP. But now we have namespaces, that were introduced
> exactly for this kind of situations. Why not take advantage of it? PHP can

Nope. The namespaces were introduced to manage deep and wide class 
hierarchies, especially large frameworks with hundreds of classes, not 
to bother little string functions that never hurt anyone.

> 2. TYPE HINTING. Currently PHP supports argument type hinting for arrays and
> objects. As I know, it's also been decided to offer support for this in
> function return values. For me it is hard to understand why not offer

Decided by whom? When?

> support for type hinting of scalar values as well. Hinting *string*, *int*,
> *float* and *bool* values can save a lot of debugging time and would provide

This topic was discussed to death on the list, please read the archives. 
If after that you still do not understand what it is about, or have some 
comments, please ask then.

> code coincides with the global namespace ( \ ) code, I think it's safe to
> remove the *define* function and possibly allow the *const *keyword to
> define runtime constants as well (when the value is not a constant
> expression).

That would not work since code can not be run when class is being 
parsed, and after that it is not clear when it is supposed to be run and 
in what context, etc. But more importantly - what for? If you need to 
calculate something, make it a variable and calculate it in the ctor. 
Constants aren't meant to be results of complex calculations, they are 
meant to be simple and fixed.
There was a proposal for read-only variables and one for per-variable 
getters/setters (actually, with some effort you can do it right now, a 
bit less efficiently maybe but doable). This might be direction to go in 
this case.

> 4. PARAMETER ORDER. As noted in an older PHP meeting:

Two letters: BC.
Changing variable order in an existing function is a big fat BC break. 
And if we put such a bomb into a new version, what would be the 
incentive for people to use it? So that apps would have to be shipped in 
2 versions, for the old php and the new php?

> These were the major issues that came to my mind until now. I am sure many
> things and ideas can be rejected with the reason of backward compatibility
> and fear of breaking tons of lines of ancient code. But existing code can

Please remember - what you call "ancient code" other people call 
"application on which my paycheck depends". So I think we should be 
super-extra-careful when messing with it. That doesn't mean we would 
never do any BC-breaking change ever - that does mean there always has 
to be a very good reason for it. And I personally don't see 
"consistency" being good enough reason. Don't get me wrong - it's good, 
it's just not good enough to be valued over working applications.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com