Re: [RFC Proposal] var keyword deprecation/removal

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]