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