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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
