Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88912
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain siobud.com designates 104.236.58.159 as permitted sender)
Date: Wed, 21 Oct 2015 12:39:08 -0500
To: Aaron Piotrowski <aaron@icicle.io>
Cc: danack@basereality.com, PHP internals <internals@lists.php.net>
Message-ID: <20151021173908.GA27116@3006.local>
References: <20151020173602.GA92318@3006.local>
 <CA+kxMuSRFiM7nO0xZprzzEa7KNk8Yh8bm2xsSF0Edhhcoun50A@mail.gmail.com>
 <20151021161740.GA23933@3006.local>
 <E4674335-E92E-4BAD-8ADC-8C67BA513763@icicle.io>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E4674335-E92E-4BAD-8ADC-8C67BA513763@icicle.io>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility
From: sean@siobud.com (Sean DuBois)

On Wed, Oct 21, 2015 at 12:31:58PM -0500, Aaron Piotrowski wrote:
> Hi Sean,
>
> > On Oct 21, 2015, at 11:17 AM, Sean DuBois <sean@siobud.com> wrote:
> >
> > On Wed, Oct 21, 2015 at 03:54:48PM +0000, Dan Ackroyd wrote:
> >> Hi Sean, internals,
> >>
> >> While I support this RFC, it seems that the actual implementation is
> >> still under discussion.
> >>
> >> In particular, whether the RFC is going to allow protected constants
> >> in an interface is not clear.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> Please can you update the text of the RFC?
> >>
> >> Unfortunately, that may need a restart of the voting :-\ However that
> >> should just be a formality as it seems to be a popular RFC.
> >>
> >> cheers
> >> Dan
> >>
> >> --
> > Hi!
> >
> > That is an unfortunate mistake on my part. The *proper* way to adjust
> > visibility of a trait from a class constant is the following.
> >
> >    trait myTrait {
> >        public const FOO = 'bar'
> >    }
> >
> >    class myClass {
> >        use myTrait { FOO as protected; }
> >    }
> >
> >    class myClass {
> >        use myTrait { FOO as private; }
> >    }
> >
> > We should not allow anything besides public in trait, this mirrors the design of methods.
> >
> > 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?
> >
> > thanks
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> 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’t make sense for an interface. I think the RFC should be updated to remove this ambiguity.
>
> I’m 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
>
>
Argh I am rushing, again my mistake.

I just updated the RFC to reflect this, sorry about the confusion
everyone! The intent of the RFC is to just copy existing patterns from
methods/properties so as non-controversial as possible.

For now I am not going to restart the vote, if anyone feels
this decision is wrong I am more than happy to restart the vote.
However, don't want to inconvenience the people who have already taken
time to vote.

thanks!