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

On Mon, Sep 7, 2015 at 7:11 PM, Xinchen Hui <laruence@gmail.com> wrote: > > > Sent from my iPhone > > > On Sep 8, 2015, at 02:09, Andrea Faulds <ajf@ajf.me> wrote: > > > > Hi Stas, > > > > Stanislav Malyshev wrote: > >> > >> 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, > > > > Why not? A constant's value doesn't change at runtime, but nothing stops > you changing the value in a new version. A real-world example for you: > phpng changed the values of the IS_* constants in the Zend Engine. > > > >> 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). > > > > Constants in code aren't necessarily natural constants. > > > > 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? > > > > If I have a value specified in the source code which will not change at > runtime, and which I don't want to expose as part of my public API... what > exactly do you propose it should be? I don't see why a constant isn't > fitting. > > > public static final as Java does > > https://3v4l.org/KX5jQ > PHP Fatal error: Cannot declare property Foo::$Bar final, the final modifier is allowed only for methods and classes in - on line 4 So there is no way to create an immutable property with a visibility modifier, unless you're suggesting that's what the RFC should be instead.