Code: Select all
preg_match('/^[0-9]+$/', $string)As for the bashing, well this is the Critique forum, it's not the "Pat on the back and a congratulations" forum.
Moderator: General Moderators
Code: Select all
preg_match('/^[0-9]+$/', $string)Yes I doYou've got nothing to test if it is a "smallint", "bigint" or other variation
Code: Select all
public function invoke(array $testSubjects, $signed = false, $maxInt = PHP_INT_MAX)It's part of the core, and is faster and more secure that PCRE. But if it makes you happy you could write this:for a start, you are dependent on ctype - which is an optional extension
Code: Select all
private function _unsigned($testSubject)
{
// its obviously false if it contains non-digit characters
if (function_exists('ctype_digit')) {
if (!ctype_digit($testSubject)) {
return false;
}
} else if (!preg_match('/^\d+$/', $testSubject)) {
return false;
}Code: Select all
is_numeric()Doesn't just check for integers.jmut wrote:How about? Nobody mentioned this one.Code: Select all
is_numeric()
Ctype is available in approximately 95% of all PHP installations vs 97% for PCRE. PCRE is also entirely optional (oh yes it is!) and was only available by default since PHP 4.2.0. Along with a lot of extensions oddly enough... If a PHP installation does not have ctype enabled than it needs updating...not pandering.ctype is only available by default on PHP installations => PHP 4.2.0.
Are you implying my my code insufficient in this regard?The killer feature in this case is making sure the integer doesn't overflow. This is slightly more complicated than one would expect, since counting the number of digits is not sufficient.
For some reason I wanted to write the most complete integer validation and I just thought "hey if its too big its not going to be an integer" and wrote the validations. I think you guys have done a pretty good job of convincing me that it is not the responsibility of integer validation to ensure an integer is within storable range and if you want to do that there should be a separate numeric range validation (which I have). That keeps thing small, simple and single responsabilitifiedkeep in mind that nearly all databases will gracefully handle insertions of numbers that overflow by clipping them, and if this is a necessary error condition MySQL can operate in Strict mode, which will fail the query if there's an overflow
And bcmath for outside of that.. its in my code towards the bottom.we can use PHP's regular integer comparison functions to determine whether or not 888 will fit in a TINYINT column (it won't).
Yeah, that would make it more useful. But, going back to the main issue, it is necessary to do this at all? I always validate a string is less than 255 chars if its going in a varchar because I don't want the user to experience truncation unexpectedly. Perhaps the principle only applies to small integers where an overflow is more likely. And again you probably want a separate range validation because you don't want a "not an integer" error when you really me "number is too large".The main probably I see, as of right now, is that you expect the user to know what the max value is. They probably don't. All they know is that they're validating for a TINYINT: your class needs to account for that.
Besides the one I posted?Also, you need some unit-tests.
Yes, you are right.I believe that -128 is a valid value for a signed TINYINT, but 128 is not.
But that is what they are most commonly assoicated with and this is important when you consider that a one of the good reasons for using them is the readability they add.Exceptions aren't solely for serious or unexpected errors.
And this is probably the only functional advantage to using them and inappropriate, given my current implementation. Presently I'm using a component paradigm to invoke validations and store the error message and its destination, if the destination is missing no error message is displayed, not optimal but better than fatality surely.They are a facility for passing the error handling to a layer above the current one. That may be the calling layer, but could be higher.