Re: [RFC Proposal] var keyword deprecation/removal

From: Date: Mon, 29 Feb 2016 11:34:43 +0000
Subject: Re: [RFC Proposal] var keyword deprecation/removal
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-91458@lists.php.net to get a copy of this message
Tony Marston wrote on 29/02/2016 09:55:
"James Titcumb" wrote in message news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...
On 28 Feb 2016 06:18, "Jakub Kubícek" <kelerest123@gmail.com> wrote:
I see a difference in its _semantics_. While the public modifier states anyone can change the property, var is useful for marking internal properties which must be public, but should not be manipulated by simply anybody
If it's public, it will be modified by someone.
Incorrect. It *may* be modified, but surely any invalid modifications will be detected in the testing phase?
Detected by whom? Using what tool? I'm not aware of any generic way of logging all access to particular properties, nor quite what "invalid modifications" mean in this labelling scheme. Maybe it would be detected during *review*? Apologies if that's what you meant and the distinction sounds pedantic. A better way to mark this kind of distinction is using PHPDoc annotations, which can be made readable by both humans and tools. For instance, PHPStorm will cross through any uses of a property marked "@internal"; I wouldn't be surprised if other IDEs and tools can pick this up as well. In this case, you could just use the fact that the property is labelled "@inject" to mark the distinction, and you'd be no worse off in terms of tooling support than you are now (i.e. IDEs will not come with this interpretation of "var" baked in anyway). Regards, -- Rowan Collins [IMSoP]

« previous php.internals (#91458) next »