Feasibility of additional support around constants. View as Markdown

Hi.

Some extensions provide a lot of constants. Currently, there is no
mechanism to group related constants.

Whilst many constants are prefixed with the extension name, within
that group, there is no standardised way to further group them.

Also, there is no way to reverse the mechanism. From a value, what is
the constant's name that would have been used in userland code?

It would be useful to have the ability to
tag/group/block/enum/const-array/etc. to form a collection of
constants so that from userland, you can easily identify the name of
the constant you have received.

I suppose, this is mainly useful where the userland code is a layer of
some sort, something that has to validate or extrapolate values
further down the chain and report back on them.

There are 3 main uses I can think of which would be useful.

1 - Validating that the value received is in a collection of known
constants. This would allow for new constants to be added without the
layer having to be amended to verify the value. If it isn't in the
group - it's invalid.
2 - For a constant value, report back the actual name of the constant.
The user supplied the value of 4 to the function. The function failed
for some reason and in the ensuing exception report, showing the name
of the constant would be extremely useful. Not all the extensions
document the value of the constants, so knowing what 4 is in't
instantly available.
3 - If the collection is a set of bitmasks (error_reporting for
example), then report back the constants that make the value.

This can all be done in userland code with some degree of simplicity,
but amending the code for each new constant seems that it should be
unnecessary.

Now, you may think, why not use Reflection? Yes. I have done that but
you can't easily group the constants. There are many constants set to
the value of 2 (for example).

All of these are from the standard extension.

Constant [ integer CONNECTION_TIMEOUT ] { 2 }
Constant [ integer INI_PERDIR ] { 2 }
Constant [ integer PHP_URL_PORT ] { 2 }
Constant [ integer PHP_ROUND_HALF_DOWN ] { 2 }
Constant [ integer INFO_CREDITS ] { 2 }
Constant [ integer CREDITS_GENERAL ] { 2 }
Constant [ integer ENT_COMPAT ] { 2 }
Constant [ integer STR_PAD_BOTH ] { 2 }
Constant [ integer PATHINFO_BASENAME ] { 2 }
Constant [ integer LC_CTYPE ] { 2 }
Constant [ integer SEEK_END ] { 2 }
Constant [ integer LOCK_EX ] { 2 }
Constant [ integer STREAM_NOTIFY_CONNECT ] { 2 }
Constant [ integer STREAM_NOTIFY_SEVERITY_ERR ] { 2 }
Constant [ integer STREAM_FILTER_WRITE ] { 2 }
Constant [ integer STREAM_CLIENT_ASYNC_CONNECT ] { 2 }
Constant [ integer STREAM_CRYPTO_METHOD_SSLv23_CLIENT ] { 2 }
Constant [ integer STREAM_SHUT_RDWR ] { 2 }
Constant [ integer STREAM_PF_INET ] { 2 }
Constant [ integer STREAM_SOCK_DGRAM ] { 2 }
Constant [ integer STREAM_PEEK ] { 2 }
Constant [ integer FILE_IGNORE_NEW_LINES ] { 2 }
Constant [ integer FNM_PATHNAME ] { 2 }
Constant [ integer PSFS_PASS_ON ] { 2 }
Constant [ integer PSFS_FLAG_FLUSH_CLOSE ] { 2 }
Constant [ integer LOG_CONS ] { 2 }
Constant [ integer EXTR_PREFIX_SAME ] { 2 }
Constant [ integer SORT_STRING ] { 2 }
Constant [ integer ASSERT_CALLBACK ] { 2 }
Constant [ integer STREAM_IGNORE_URL ] { 2 }
Constant [ integer STREAM_URL_STAT_QUIET ] { 2 }
Constant [ integer STREAM_OPTION_READ_BUFFER ] { 2 }
Constant [ integer STREAM_BUFFER_FULL ] { 2 }
Constant [ integer IMAGETYPE_JPEG ] { 2 }
Constant [ integer DNS_NS ] { 2 }

I think that extending the struct _zend_constant to include a constant
group number in addition to the existing module number, should be
enough in terms of storage (an extra int per constant). The
REGISTER_xxxx_CONSTANT macros and their module specific clones would
been to be extended to allow for the constant group property to be
set, though a mechanism to supply a default for the constant group
would be a good thing I think so that untouched extensions still
report their constants as belonging to the to the unassigned group.

I guess that covers the ground work.

There would need to be a few new built-in functions to allow access to
the name and for the decomposition of the bitmask to its constituent
values.

Each extension would need to be amended to provide the additional
facilities - though, hopefully, this would be nothing more than adding
the constant group number to the constant creation macro call.

And the get_defined_constants() function could be amended to from ...

array get_defined_constants ([ bool $categorize = false ] )

to

array get_defined_constants ([ int $categorization_depth = 0])

where 0 is none, 1 is the same as true at the moment and 2 would be by
extension and then by each group.

If the additional grouping was alpha, rather than numeric, that would
help further I think (removing the magic numbers).

Is this anything that is ...

a - Useful
b - Doable

Regards,

Richard Quadling.

--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY