Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <20151021161740.GA23933@3006.local>
Date: Wed, 21 Oct 2015 12:31:58 -0500
Cc: danack@basereality.com,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E4674335-E92E-4BAD-8ADC-8C67BA513763@icicle.io>
References: <20151020173602.GA92318@3006.local> <CA+kxMuSRFiM7nO0xZprzzEa7KNk8Yh8bm2xsSF0Edhhcoun50A@mail.gmail.com> <20151021161740.GA23933@3006.local>
To: Sean DuBois <sean@siobud.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility
From: aaron@icicle.io (Aaron Piotrowski)

Hi Sean,

> On Oct 21, 2015, at 11:17 AM, Sean DuBois <sean@siobud.com> wrote:
>=20
> On Wed, Oct 21, 2015 at 03:54:48PM +0000, Dan Ackroyd wrote:
>> Hi Sean, internals,
>>=20
>> While I support this RFC, it seems that the actual implementation is
>> still under discussion.
>>=20
>> In particular, whether the RFC is going to allow protected constants
>> in an interface is not clear.
>>=20
>> In the text of the RFC, on one line it says: "This RFC propose PHP
>> support class constant visibility that mirror the behaviour of method
>> and property visibility." This would imply that protected constants
>> are not allowed, as protected methods are not allowed in interfaces.
>>=20
>> Just below it says: "//Interfaces only support protected/public =
const,
>> and a compile time error will be throw for privates" Which says
>> clearly that protected constants _would_ be allowed.
>>=20
>> Please can you update the text of the RFC?
>>=20
>> Unfortunately, that may need a restart of the voting :-\ However that
>> should just be a formality as it seems to be a popular RFC.
>>=20
>> cheers
>> Dan
>>=20
>> --
> Hi!
>=20
> That is an unfortunate mistake on my part. The *proper* way to adjust
> visibility of a trait from a class constant is the following.
>=20
>    trait myTrait {
>        public const FOO =3D 'bar'
>    }
>=20
>    class myClass {
>        use myTrait { FOO as protected; }
>    }
>=20
>    class myClass {
>        use myTrait { FOO as private; }
>    }
>=20
> We should not allow anything besides public in trait, this mirrors the =
design of methods.
>=20
> If this is right (mind just sending an ACK to make sure I got it right =
this time) I
> will update the RFC. Who decides if/when we should restart voting?
>=20
> thanks
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

I think you may have misunderstood. Traits should be able to have =
protected and private constants. The issue that Dan pointed out is with =
an interface having a protected constant in the example code, =
contradicting what was written prior in the RFC about mirroring the =
current behavior of method and property visibility.

Interfaces should only be allowed to have public constants. Protected =
constants would infer that the interface knows something about =
implementation, which doesn=E2=80=99t make sense for an interface. I =
think the RFC should be updated to remove this ambiguity.

I=E2=80=99m not sure if this would require the vote to be restarted, as =
I doubt anyone who voted yes would now vote no with this change.

Regards,
Aaron Piotrowski