Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com>
 <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com>
 <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com>
 <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com>
 <56D86C00.6000904@fleshgrinder.com> <56D870FC.80205@gmail.com>
 <56D8752A.9040307@fleshgrinder.com>
Message-ID: <56D878E9.3060907@gmail.com>
Date: Thu, 3 Mar 2016 17:48:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56D8752A.9040307@fleshgrinder.com>
Content-Type: multipart/alternative;
 boundary="------------050304020406080709050600"
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: rowan.collins@gmail.com (Rowan Collins)

--------------050304020406080709050600
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Fleshgrinder wrote on 03/03/2016 17:32:
>> If there were some way of preventing users writing var in*new*  code, I
>> >would be all for it - there is no advantage to doing so, and it adds no
>> >value to have two ways of writing "public". But there is no way for the
>> >engine to distinguish new code from "legacy" code which already contains
>> >the keyword. If someone can come up with a clean mechanism for doing
>> >that (and in particular, for new code to say "I'm including this legacy
>> >library which I will replace with modern code shortly, don't bother
>> >telling me how many deprecated features it uses"), then I would be very
>> >interested.
> I always thought that E_STRICT is exactly that. I mean, an upgrade path
> like ...

There's a subtle distinction which I may not have explained very well. 
What I want is the ability to *selectively* ignore these warnings. For 
instance, if I write:

namespace \Foo\Bar\Baz;
class AwesomenessFactory implements ArrayAccess {
     var $something;
}

... then I would be happy to see a notice that I'd used the wrong keyword.

But if I write:

# TODO Replace dependency with modern equivalent
include 'Ancient/PEAR/Library.php';

... then I don't want to see 500 notices that the library I'm about to 
replace has old-fashioned code in it. The same is true if I am actually 
maintaining the included library, and have a rewrite in the works which 
I am confident will supersede the current stable version long before the 
next major version of PHP.

It's not about whether those notices are there for 6 years or 9 years, 
or which E_* constant they appear under, it's about granularity of which 
ones shout at me.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------050304020406080709050600--