Re: [RFC] [VOTE] Class Constant Visibility

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!