Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91634
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: internals@lists.php.net
References: <CAJaRsPu+1-4smkTLACKFavHKqED0gBrz-w42wAVXvj-mYKHZNA@mail.gmail.com>
 <CAHvhOfhHUdjuF6J26_gsW+wTQBYRNNbpZsP1p_b9dwK=PC9vCw@mail.gmail.com>
Message-ID: <56E2A454.7090206@gmail.com>
Date: Fri, 11 Mar 2016 10:56:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAHvhOfhHUdjuF6J26_gsW+wTQBYRNNbpZsP1p_b9dwK=PC9vCw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC Discussion] "var" Deprecation
From: rowan.collins@gmail.com (Rowan Collins)

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]