Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAHvhOfhHUdjuF6J26_gsW+wTQBYRNNbpZsP1p_b9dwK=PC9vCw@mail.gmail.com>
References: <CAJaRsPu+1-4smkTLACKFavHKqED0gBrz-w42wAVXvj-mYKHZNA@mail.gmail.com>
 <CAHvhOfhHUdjuF6J26_gsW+wTQBYRNNbpZsP1p_b9dwK=PC9vCw@mail.gmail.com>
Date: Fri, 11 Mar 2016 12:27:31 +0200
Message-ID: <CAL0xaBEuBMuO9gYkqBDzuLobh7fEoneybQ-WBVOFZq78hXyNXQ@mail.gmail.com>
To: =?UTF-8?B?SmFrdWIgS3Viw63EjWVr?= <kelerest123@gmail.com>
Cc: "Colin O'Dell" <colinodell@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b5d4a2612cbce052dc36203
Subject: Re: [PHP-DEV] [RFC Discussion] "var" Deprecation
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--047d7b5d4a2612cbce052dc36203
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-03-11 12:03 GMT+02:00 Jakub Kub=C3=AD=C4=8Dek <kelerest123@gmail.com>:

> From the RFC:
>
>
> > var is therefore a limited subset of public.
>
>
> No, this is wrong. `var` was here much much longer than `public`, therefo=
re
> `var` is not a subset of public, but rather `public` is _an extension_ of
> `var`. 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
> - `var` can semantically also represent an internal dependency, as I have
> described earlier
>
> On 10 March 2016 at 22:44, Colin O'Dell <colinodell@gmail.com> wrote:
>
> > Hello all,
> >
> > I have completed my initial draft of the RFC to deprecate "var" in favo=
r
> of
> > "public": https://wiki.php.net/rfc/var_deprecation
> >
> > I would greatly appreciate any feedback on this RFC, especially with th=
e
> > following:
> >
> > - Ensuring that all major arguments for & against have been documented.
> > - Any impact this may have on SAPIs, extensions, or the opcache.
> > - Any assistance or guidance on creating the patch (I've never written =
C
> or
> > worked with the core codebase before).
> >
> > If you'd like to read the pre-draft discussion it can be found here:
> > https://wiki.php.net/rfc/mailing_list_discussion
> >
> > Regards,
> >
> > Colin O'Dell
> >
>
>
>
> --
> Cheers,
> Kubis
>

I'm gonna fire anyone who does anything like you described from my company
straight out the door no questions asked. Period.

var $_id; =3D> is that intended to be "private"? But I can access as a
public. Or is it meant to be "protected"? Can I actually modify it directly
or is there a setter/getter? IDE gives me autocomplete from outside of the
object, then I surely can do $object->_id =3D $something;
var $id; =3D> Well, all of the above.
Internal dependency? Good god, that's what private/protected are for.
You really overestimate how much people really care about the 3rd party
code and how it's intended to be used. I know of instances that people just
took 3rd party code, modified some property to be public and didn't give a
damn about that. And you want to define internal properties as "var
$property" to be available for public access?
If some project is using "var" as a special snowflake, well, it's their
problem, not the communities. And our PHP community is so large, that even
projects like Symfony aren't really dominating the landscape, and those
guys do have influence.

Sorry, but that's just bad decision making.
Also, there are docs, official docs here
http://php.net/manual/en/language.oop5.visibility.php that state:

"Class properties must be defined as public, private, or protected. If
declared using var, the property will be defined as public."

Sorry, but "var" is a legacy at this point. No sane code is written using
it, you don't even have a dedicated manual page or paragraph for it, just a
single line stating that "var is essentially public". And replacing var
with public is already automated for you with a script provided with the
RFC.

I'm sorry for my ramblings, but I just couldn't leave statements like that
without opposition.

--047d7b5d4a2612cbce052dc36203--