Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91659
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.50 as permitted sender)
MIME-Version: 1.0
References: <CAJaRsPu+1-4smkTLACKFavHKqED0gBrz-w42wAVXvj-mYKHZNA@mail.gmail.com>
 <CACwt+JfGyu=Qp-UnLHBjBX4Yc=0T8ii=UD2wCqJQxt5QNffDzg@mail.gmail.com>
In-Reply-To: <CACwt+JfGyu=Qp-UnLHBjBX4Yc=0T8ii=UD2wCqJQxt5QNffDzg@mail.gmail.com>
Date: Mon, 14 Mar 2016 18:14:02 +0000
Message-ID: <CAJaRsPv4wRVJBrRotXpwvd4etB0=j2Nh=vODCOgaM9waE5C=aQ@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140fa16678fa2052e063f75
Subject: Re: [PHP-DEV] [RFC Discussion] "var" Deprecation
From: colinodell@gmail.com ("Colin O'Dell")

--001a1140fa16678fa2052e063f75
Content-Type: text/plain; charset=UTF-8

>
> Forcing people to specify a visibility for properties and not for methods
> would add yet another inconsistency in the language.
>

That's a really good point.  However, I think we currently have a different
inconsistency: declaring functions without explicit visibility is possible
without needing an extra (and redundant) keyword.

The inconsistency you mention could easily be solved by a future RFC.  We
could:

  1. Require visibility for class methods.
  2. Allow declaring properties without using any keywords.
  3. Use some other approach?

I don't think we necessarily need to choose an option at this time (or
perhaps ever).


> #1
> class Example {
>     var $foo;
> }
>
> #2
> class Example {
>     public $foo;
> }
>
> #3
> class Example {
>     public function __construct() {
>         $this->foo = null;
>     }
> }
>
> If I understand this RFC, example #1 is handled by it, but not #3.
> Using #1 would emit a deprecation notice, but #3 wouldn't?
>

Correct.  This RFC only targets the deprecation and removal of T_VAR.


> As far as I am concerned, I think it is still better to declare the
> properties rather than not and this RFC would (somehow) favour not
> declaring them at all than doing so with "var".
>

I disagree - this RFC does not prevent anyone from declaring properties,
you just need to explicitly declare the visibility.


> I'm generally in favour of not having duplicated ways of doing the exact
> same thing.
> I'm generally in favour of not introducing (uneeded) BC issues.
> I'm not convinced that the number of people that will benefit the
> uniqueness of declaring a variable would be greater than the one suffering
> upgrade issues.
>

I disagree on the third point - I think the automated upgrade process is
literally the second-easiest upgrade possible (#1 would be no changes
required).  Nevertheless, I truly appreciate you considering and weighing
the different aspects of this proposal.  I'm hoping others will take a
similar approach in deciding whether they support this RFC.

Thanks for your feedback!

Colin

>

--001a1140fa16678fa2052e063f75--