Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50812
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=VKOJDWOhKZW9GHBOsdYc1KRM7ZErr6AAcyJO6zkC7VXt4gdxwgwlzT8XqDzajjtq2b
         seiCTKTkrgMURvSFDyenlpB9OD3zN5/q+oxVLaKKMGQZ7RjOjZZdT1CY1z54PTNEWh6h
         CpWJE2TorY7Ft6/LqwIRqJPbo2m/WUbjcoTsI=
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <AANLkTimwb_UyAr5v-y0zbn3itkFunMGXj973POZmbQvm@mail.gmail.com>
References: <1290879624.7033.826.camel@guybrush>
	<AANLkTi=174erSkzXxc+bci7P3qB0j2LWZaCnGF2H6_D2@mail.gmail.com>
	<AANLkTinNnhAc3_5BidBxsMG0nY=5pPO+k4BQ_-d5P0xg@mail.gmail.com>
	<AANLkTimYtyunn+Jun-OkTXr=XQK3pxD9yLNOMn5AQJOB@mail.gmail.com>
	<AANLkTikQu9M62XJvJ9mYT_qELN96Zqv7-KiG6sar81u-@mail.gmail.com>
	<AANLkTikhg2mwy+YNXGTrMYsZ=v6hw=VWFk6QakFU_qXB@mail.gmail.com>
	<AANLkTimwb_UyAr5v-y0zbn3itkFunMGXj973POZmbQvm@mail.gmail.com>
Date: Thu, 2 Dec 2010 14:51:57 +0100
Message-ID: <AANLkTinUygfL-5n1Gk5bi0a9tnsjOX=hWeb4pust1yp9@mail.gmail.com>
To: Peter Beverloo <peter@lvp-media.com>
Cc: =?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?= <ar@ez.no>, 
	Kalle Sommer Nielsen <kalle@php.net>, =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
From: patrickallaert@php.net (Patrick ALLAERT)

2010/12/2 Peter Beverloo <peter@lvp-media.com>:
> On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT <patrickallaert@php.net> wr=
ote:
>> 2010/12/2 Andr=C3=A9 R=C3=B8mcke <ar@ez.no>:
>>> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT <patrickallaert@php.ne=
t>
>>> 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 n=
ot 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!

--=20
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor