> > 2) your isValid("integer") test does something like just checking it
> > it's numeric and has no decimal part. This would be fair enough in
> > the "real world", but I think in the computer world, a number is only
> > an integer it fits into an integer data type.
>
> The "integer" tests basically if its non-decimal, so long's fall under
> this remit too. This is something we could probably tighten up without
> anyone noticing the reduced window of number of ranges.
>
> As for the other issues, can you update the bug report and we can
> discuss it there, and i will get to it when i can.
OK. We didn't actually have a bug report for this before, we just
dealt with it here. But I've now raised
http://code.google.com/p/openbluedragon/issues/detail?id=251.
A note on the "Long" thing you mention. BD won't handle a Long (-
(2^63) -> (2^63)-1) without converting it to a floating point number
(nor will CF for that matter), and accordingly failing the test. But
I see what you're getting at. I think the maximum sensible range you
could legitimately accept is "integers up to a threshold over which BD
will convert them to floating point". That makes some sense. However
just using the standard range of what constitutes and "Integer"
datatype makes more sense.
Either way, I've changed my validator to just check the various
requirements by hand, so my unit tests all pass on both CF & BD, and
the issue is moot for me now :-)
Cheers.
--
Adam
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
online manual: http://www.openbluedragon.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en
