Re: Custom types and default values

Greg wrote:
> I think this is very easy to fix with a minor tweak to my original
> proposal: if a default value is a string, pass it to the type conversion
> function; otherwise, leave it alone.  This presumes that the output of
> most type conversions are not strings, which seems reasonable to me --
> why would you go to the trouble of writing a custom type if not to
> convert a string from the command-line to something more usable?  (But
> then, I haven't written any custom types, except for example code, so I
> really don't know how [or if] they are used in the real world.)

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.

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.

Perhaps that's a crazy scenario.  Anyway, I'm looking forward to these 
improvements regarding defaults.

Regards,
-John


-- 
http://giftfile.org/  ::  giftfile project


-------------------------------------------------------
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