Re: Custom types and default values
Greg Ward <[email protected]> Mon, 31 May 2004 21:18:15 -0400
| Newsgroups | gmane.comp.python.optik.user |
|---|---|
| Message-ID | <[email protected]> |
On 29 May 2004, John Belmonte said:
> Hmm... I guess that will work, but it only takes one person out there
> doing a string->string conversion to make this not backwards compatible.
OK, as soon as I hear from that person, I'll come up with a better idea.
> I'm wondering if you will still be promoting the use of non-string
> defaults for types built into optik. I can image some trouble
> situations, for example you have an int option with a default of 99.
> Then you change the option to a custom type that is an integer with
> range checking, and the range is set to [1, 50]. Since the default is
> not passed through the type checker, the invalid value isn't caught,
> violating an invariant of the program.
Red herring on two counts: if allowing that scenario is an Optik bug,
it's already a bug in 1.4.1, because you *must* specify
post-type-conversion values there. Optik 1.5 will allow you to specify
strings (pre-type-conversion values), but most certainly will not
require it -- that would break everything!
Second, if an application breaks its own invariant, that's not an Optik
bug, it's an application bug. Too bad.
Greg
--
Greg Ward <[email protected]> http://www.gerg.ca/
Speak softly and carry a +6 two-handed sword.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click