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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php