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

Hi Sean,

Sean DuBois wrote:

I am starting this discussion to get peoples opinion on the overall feature, and find someone
who would be interested in watching over my progress and making sure I
do the right things to hopefully get this merged.

The PHP bug tracker contains a few simple entries for a adding visibility modifiers to class constants.
https://bugs.php.net/bug.php?id=27022

I would be the one implementing this, and have a basic working version already (that
takes shortcuts like reusing property_info) but it works!
https://github.com/Sean-Der/php-src/compare/master...bug-69980-class-constants#diff-6231c13c8582758f41a5e2a015e3b5c5R1
There are cases where runtime/compile time checks pass/fail incorrectly,
but working on that now.

This change would involve breaking the API, but wouldn't involved any
language breaking changes. All current const declarations would just
default to public and keep the same behavior.
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?

I'd love to see this in PHP. Are you going to write an RFC?

Thanks!

Andrea Faulds
http://ajf.me/

Just one of those things that you you wish you had, but then end up
solving with other things (static properties) so we will see how long it
takes me to blunder through it :)

Reeze Xia started an RFC, but didn't have time to finish it. We talked
over GitHub and I will be taking it over fully.
https://wiki.php.net/rfc/class_const_visibility

I am just waiting on RFC Karma, after I get that I will start filling it in!
I really like this feature but please make sure it doesn't break BC on
usage of Reflection::getConstant(s).
For example I'm using this for an implementation of constant based
enumerations:
(https://github.com/marc-mabe/php-enum/blob/master/src/Enum.php#L277)

Marc

However, I have hard time seeing how that would apply to constants

I don't see what their not changing has to do with their visibility.

It's not hard to see a legitimate use case for private constants, a case
that springs to mind is where you use a public bitmask for some
configuration option but want to keep the shift or mask constants private,
because they might change, and you don't want to leak that implementation
detail. They are still constant at runtime, but over the course of the life
of the codebase they can definitely change, and, they shouldn't be a static
member or normal variable.

On Mon, Sep 7, 2015 at 8: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?

Stas Malyshev
smalyshev@gmail.com

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)

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)

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.

Thanks.

--
Andrea Faulds
http://ajf.me/