Re: Re: [RFC] [Concept] Class Constant visibility modifiers in PHP 7.1+

On Mon, Sep 7, 2015 at 6:24 AM, Ryan Pallas <derokorian@gmail.com> wrote: > > > On Mon, Sep 7, 2015 at 1:02 AM, Stanislav Malyshev <smalyshev@gmail.com> > wrote: > >> Hi! >> >> > Funny you should propose this now, I was wanting this feature just the >> > other day. This would be a useful addition, and clean up a strange >> > inconsistency: why can methods and properties have visibility modifiers, >> > but not constants? >> >> Private and protected methods and properties are private for a reason - >> they may be radically changed or gone when the code is changing, and >> thus external code should not rely on them, and the way to ensure it is >> to deny that code access to them. However, I have hard time seeing how >> that would apply to constants - they shouldn't really change, and if >> they do, they either shouldn't be constant, or something in your world >> changed fundamentally (i.e. scientists discovered that PI actually >> equals to 4). I wonder if you find in your code constant that you need >> to hide because you foresee it changing - should it really be a constant >> at all? >> > > > For me a common use case is DB abstraction. I have an abstract base class > that implements a bunch of functionality based on protected static members, > which are to be set in the implementing class. Now these properties are > constant for the implementing class (table name, column definition, etc) > but I have to put them in a static member to prevent outside access. So > now I have the problem, where if someone else maintains my code they see a > static member in the class they may think its acceptable to change it in > some function at run time, meanwhile if they were constants it would be > very obvious that they should not be changed. The reason they are in static > members is A) to provide visibility modifiers and B) to share a single > value across all instances, however given that C) they are constant through > meaning and usage, the should instead be protected consts. For an example > of a base class of this type, you can look at my framework's version (NOTE: > I'm not advocating my framework, its kinda crap but it works well for my > purposes) http://bit.ly/1EN59Ty (class) > http://bit.ly/1NdkGgL (docs) > Looks like I changed to constants because someone did write a function that modified the value of TABLE_NAME in a project I was working on. So now the internals of the models are available everywhere (sad). > I fully support this idea, and would be glad to provide any help I can > (though that probably just means writing tests since I don't know C) >