2010/12/2 Peter Beverloo <pe...@lvp-media.com>: > On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT <patrickalla...@php.net> wrote: >> 2010/12/2 André Rømcke <a...@ez.no>: >>> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT <patrickalla...@php.net> >>> wrote: >>>> Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ >>>> introducing the possible omission of T_FUNCTION? >>> >>> Why? >>> This will break lots of code, does it improve anything while at it? Is 'var' >>> hindering anything? Is it taking up a lot of code? >>> If it is removed then that should be in trunk aka "6.0" the 2nd , and not in >>> 5.x. >> >> It should of course not appear in a 5.x release! But sounds like >> current trunk can't be anyway. >> >> +1 for removing T_VAR and making T_FUNCTION optional in a major release. >> -1 otherwise. >> >> -- >> Patrick Allaert >> --- >> http://code.google.com/p/peclapm/ - Alternative PHP Monitor >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > An entire major version relied on the usage of T_VAR within classes. > Many people still use it today. > I therefore am strongly against removing T_VAR, considering it would > break huge amounts of userland code.
If people migrate to a major version of PHP > 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. > In either case, it should be > deprecated with an E_DEPRECATED warning during at least another major > before it gets removed. This makes much sense! -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
