Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82586
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <B2B81CE3-F7ED-4CC0-8E14-8E6B89F126DD@ajf.me>
References: <CAJbumGNuTdoFJCEB31+q9WJUCW=GPMwkB1McFq0HdwOsHB39Cg@mail.gmail.com>
 <B2B81CE3-F7ED-4CC0-8E14-8E6B89F126DD@ajf.me>
Date: Fri, 13 Feb 2015 17:27:56 +0900
Message-ID: <CAGa2bXaCX1JJMPrJzkdYZhjC8Gn2oJ7EkTVy8xampwKVtWDOTA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: pierre@pcservice.co.za, PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11336798df58a0050ef40501
Subject: Re: [PHP-DEV] [RFC] Deprecate properties using var
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11336798df58a0050ef40501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Thu, Feb 12, 2015 at 8:57 PM, Andrea Faulds <ajf@ajf.me> wrote:

> > On 12 Feb 2015, at 11:51, Pierre du Plessis <pierre@pcservice.co.za>
> wrote:
> >
> > Before I create an RFC, I just want to get some feedback on a proposal,
> to
> > deprecated the use of "var" when declaring properties on a class.
> >
> > This was previously deprecated in PHP 5.0.0 and the deprecation notice
> was
> > removed  in PHP 5.1.3.
> >
> > My proposal is to deprecate the use of var on properties in PHP 7, and
> then
> > remove support for it in PHP 8. This compliments the [0] "Remove PHP 4
> > Constructors" RFC, as it is old PHP 4 behaviour, and according to the
> docs
> > is only "supported for compatibility reasons", and personally I think
> users
> > should be encourage to use proper visibility when defining properties.
>
> What=E2=80=99s the benefit here? It seems like a needless backwards-compa=
tibility
> break. PHP 4 constructors have been proposed to be removed because they
> cause problems (Filter::filter) and it simplifies the language. What
> problems does var cause? Its existence doesn=E2=80=99t seem to hurt anyon=
e - sure,
> using public/protected/private is better, but this only matters if you=E2=
=80=99re
> reading legacy code. I=E2=80=99d also be wary of removing it if we=E2=80=
=99re going to get
> rid of T_VAR, as that seems like a useful keyword we might reuse later. S=
o
> I don=E2=80=99t see why we need to remove this.


I thought I filed this as Trait bug, but there isn't. I might forgot to
report it.

http://3v4l.org/pL3Hr

Class calls trait function that is PHP4 constructor.
This could be resolved by removing PHP4 constructor.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11336798df58a0050ef40501--