On Mon, November 8, 2010 6:33 am, Richard Quadling wrote:
> 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.
Generally-speaking, it's valid if it's between 0 and the largest
value, rather than being in an array/list...
And, yes, updating the code to check this is really hard, unless
you're smart enough to do something like:
define('FOO_0', 0);
define('FOO_1', 1);
.
.
.
define('FOO_42', 42);
define('FOO_MAX', 42);
and then your check is on FOO_MAX, which you update when you add
another constant.
> 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.
It doesn't really take a lot of effort to copy/paste the constant
names and echo out their values...
Not that you *should* do that, as those might change in a new release,
if there is some kind of meaningful order to those constants by name,
and one is INSERTED and they were never intended to be stored
externally, much less embedded in your code...
In fact, the whole point of USING constants will be violated by using
the magic number to reverse-engineer the "name" of the constant, if
you think about it for a bit.
> 3 - If the collection is a set of bitmasks (error_reporting for
> example), then report back the constants that make the value.
Here the valid combinations may be subject to some
application-specific logic where the range would have holes in it...
E.g., 1 & 4 might be an invalid bitmask, where 1&2 and 1&8 is
perfectly valid... So I can see where this maybe needs a list of
known valid values, sometimes...
But the library itself should take care of this, and provide a
function to check the validity, not the app layer.
It's putting the burden on every single app that uses the library,
which is just fundamentally wrong.
> 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).
If you don't know which extension generated the error in the first
place, you are in REAL trouble...
So just knowing the extension and 2 ought to tell you which constant
it is...
In the rare occasion where I felt the need to reverse-engineer this,
an array like $foo_constants[ FOO_1 ] = 'FOO 1'; did the trick for me.
And, yes, updating that when constants are added is somewhat painful,
but then you'll have to update SOMETHING somewhere to get meaningful
text out of it, unless you get the parser to just slap the first
parameter to define() into the zval...
So instead of a "group number", you'd have the zval storing
'INFO_CREDITS' (for example) somehow for the 2 that goes with
phpinfo()...
> a - Useful
Honestly, not really...
I can see why it looks useful at first, but it just violates too many
principles to implement, at least as you describe it...
And storing the constant name in the zval at the time of the define()...
Come to think of it, whatever 'defined' does to look up the answer
implies that PHP is already storing the constant name *somewhere*...
How you would tie that back to the value of the constant is beyond me,
but doing that in the 'define' C codebase that seems far more simple
than making up some new "group number"...
Of course, I'm not gonna be the guy writing that code :-)
> b - Doable
Seems like a lot of effort for minimal benefit to this naive reader.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
