From: Eric Mahurin <eric_mahurin@...>
Date: 2005-09-14T23:54:52+09:00
Subject: Re: yet another simple command-line option parser

--- Gavin Kistner <gavin@refinery.com> wrote:

> On Sep 13, 2005, at 3:50 PM, Eric Mahurin wrote:
> > But, the intent is not to do something like Marshal does. 
> I'm
> > only proposiing klass.from_s methods where it makes sense,
> not
> > for handling all classes like Marshal does.  Only if you
> would
> > want to parse an object of a certain type from a human
> > readable/writable string would you want to make a from_s
> class
> > method for that type.
> 
> My problem with the RCR (which I added to the comments) goes
> like this:
> 
> #from_s is a good design pattern for your own classes. Do it.
> 
> The RCR is to change the core language classes. Why?
> It's not for convenience, because the same methods already
> exist,  
> just in different forms.
> 
> So I presume it's for consistency. The problem with this is
> that it  
> still won't be consistent, because some classes do not have
> an  
> unambiguous string->instance conversion path. String#split
> exists  
> because there are lots of real-world cases with different
> delimiters  
> for arrays. Array.from_s would need to
>    * account for this (and thus have a different interface,
> with  
> optional #split type param)
>    * not account for it (requiring #split for all
> "non-standard"  
> string cases)
>    * not exist (as your RCR seems to suggest)
> 
> If this is about object serialization and later
> deserialization,  
> Marshal and YAML and friends exist.
> 
> If this is about object deserialization only, then the real
> world  
> jumps in and says:
>    * Too many ambiguous cases to make this clear for more
> than a few  
> core classes
> 
>    * So what's the point?

It is not for consistency.  It is for converting a string to a
somewhat arbitrary class.  It doesn't need to be in every
class.  Just like #to_i is in some classes and not others. 
I've never suggested putting it in Array.  I'm also not
suggesting it be used for object deserialization.

To get an idea of the usefulness, see the example I gave.  How
would you implement this simple option parser API (what started
this thread)?

 ARGV.replace(%w(
    -n 4
    -multiplier 3.14
    -q
    -title foobar
    -pattern fo+
    -time 5:55PM
    -method downcase
    a b c
 ))
 options = argv_options(
    :n          => 1,
    :multiplier => 1.0,
    :q          => false,
    :title      => "hello world!",
    :pattern    => /.*/,
    :time       => Time.new,
    :method     => :to_s,
    :default    => 1.23
 )

#=> {:default=>1.23, :time=>Wed Sep 14 17:55:00 Central
Daylight Time 2005, :n=>4, :multiplier=>3.14, :title=>"foobar",
:q=>true, :method=>:downcase, :pattern=>/fo+/}

I don't think you'll find a cleaner/more flexible solution than
the one I gave.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com