On Wed, 15 Jun 2005 16:36:38 +0200 [EMAIL PROTECTED] (Lukas Smith) wrote: > Stanislav Malyshev 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. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
