Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16692
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <83.47.20931.45940B24@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 15 Jun 2005 17:36:05 +0200
User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050614)
MIME-Version: 1.0
References: <FE.11.20931.54730B24@pb1.pair.com>	<Pine.LNX.4.62.0506151724570.19439@shire.zend.office>	<42B03CF6.9000000@php.net> <20050615171433.22b4deb0.pierre@dotgeek.org>
In-Reply-To: <20050615171433.22b4deb0.pierre@dotgeek.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] forward compatibility "public" in 4.4
From: lists@sebastianmendel.de (Sebastian Mendel)

Pierre-Alain Joye wrote:

>>> LS>>I think its a good idea to have, to make it somewhat
>>> LS>>possible to prepare for the PHP5 E_STRICT world, while
>>> LS>>still developing PHP4 compatible code. I could for example
>>> LS>>see this help increase the PHP5 adoption inside PEAR,
>>>
>>> Like, PEAR would drop support for PHP 4.3 or it would have two
>>> copies of the code - one with public keyword and one without?
>> Currently PEAR.php requires PHP 4.2.
>> We could eventually (as an intermediate step) move this dep to
>> 4.4, not immediatly. However currently there is a strong trend to
>> create new versions of packages for the main reason of making
>> them E_STRICT compatible. However lets not get too far into the
>> PEAR politics here ;-)
> 
> I have no oppinion about public (I do not like forward
> compatibility in general :)). Abour PEAR minumum dep, we plan to
> move to 4.3 once 4.4 or 5.1 is out, but not 4.4.
> 
> My other concern is that there is other issues brought by php5,
> using public will not solve them. I do not have some in mind right
> now but sounds like a bad idea to consider a package E_STRICT
> compliant only by adding public :)
> 
>> Anyways I just wanted to give this as an example. I think its
>> much more useful for independent developers who have more control
>> over their user setups than PEAR. This allows them to make the
>> move less painful and therefore will facilitate rather than
>> prolong the move to PHP5 (which is a good thing).
> 
> My oppinion differs here, providing ways to keep php4 running will
> delay the move. They only have to add public to feel safe under
> php5.

i fully agree with Lukas

i dont think that this would delay it,

IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can not
be changed if this app should run in both Versions 4 and 5, others, like
'= new' and '=& new' can easily be adopt by just removing the '&'
without getting any NOTICE in any VERSION

i think 'var' is the most important reason for the current delay in the
move to PHP 5!

i would even go a step further:

-<ST_IN_SCRIPTING>"var" {
+<ST_IN_SCRIPTING>("var"|"public"|"private"|"protected") {


btw. PHP 4.4 should raise also a NOTICE when someone trys to overwrite
$this, as this is not possible in PHP 5


-- 
Sebastian Mendel

www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet