Re: [RFC Discussion] "var" Deprecation

Jakub Kubíček wrote on 11/03/2016 10:03:

From the RFC:

var is therefore a limited subset of public.

No, this is wrong. var was here much much longer than public, therefore var is not a subset of public, but rather public is _an extension_ of var.

This is like arguing based on the origin of a word, rather than its current meaning. Regardless of which came first, within the language as it is today, "var" can be used in certain places as a synonym of "public". That is how the engine sees it, and always has been - private and protected visibility didn't exist in PHP 4, so you could write a patched version of PHP 4 that recognised "public" as a synonym of "var", and it would behave exactly as expected.

The keyword var is also unique for it's semantics in the later versions of the language viz. previous discussion: - var represents not any certain visibility, it states that the visibility of property is yet unspecified

This is not really semantic, but pragmatic - seeing "var" is a smell that the code hasn't been updated to properly restrict visibility. It is a disadvantage of running an automated conversion script, but it is not a disadvantage of deprecation as such (which would just make the smell stronger). In fact, you could make the conversion script add a comment to each variable it changed, and get a stronger smell that way as well. e.g. "var $something;" -> "public $something; // TODO: property may not need to be public"

- var can semantically also represent an internal dependency, as I have described earlier

As others have said, this is a very odd hack added in one particular code base, as a workaround for lack of package visibility / friend methods / etc. Since it's just a convention, it could equally be done other ways, such as @internal docblock annotations or a prefix on property names - both of which would actually be more visible in IDEs. I would put this in the same class as an overheating spacebar [https://xkcd.com/1172/] - it's not the language's responsibility to support every workflow that exploits unintended functionality. Regards, -- Rowan Collins [IMSoP]