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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
