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]
