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

--- Jim Freeze <jim@freeze.org> wrote:

> On 9/13/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:
> > Thanks for the input Jim.  Comments below.  I'm also
> putting
> > this in the RCR comments.
> > 
> > No problem.  Fixnum inherits from Integer.  Do you care
> whether
> > Fixnum.from_s returns a Fixnum or a Bignum?  It could
> return
> > either just like many of the other Fixnum instance methods.
> 
> I was just thinking it would be strange for me to write
> 
>   Fixnum.from_s(...) 
> 
> and get back a BigNum.
> 
> The natural thing to do is to have it return a BigNum, but
> that
> is not what was requested. The symmetric thing to do (see
> below)
> is to have it raise an exception, but that would have little
> use and
> be quite annoying.

From my perspective, the only reason for the distinction
between Fixnum and Bignum is the efficiency (runtime and
memory) of Fixnum - a very good benefit.  Otherwise, I think
you should consider them the same.  Many of the methods in
Fixnum and Bignum can return either a Fixnum or Bignum. 
(Fixnum/Bignum/Integer).from_s would be no exception.  I just
think of Fixnum and Bignum being the same type.

> > > 2. Do we use to_i or Integer(#) - Integer raises and to_i
> > > does not
> > > 3. Do we use Float or to_f - Float raises and to_f does
> not
> > 
> > Good point.  This RCR should to specify this.  I would
> think it
> > best if an exception occur if the full string doesn't parse
> the
> > the target type.  I'll change the implementation to use the
> > methods that raise exceptions.
> 
> In the two cases above I think an exception should be raised.
> 
> > require 'parsedate'
> > class MyTime < Time
> >   def self.from_s(s)
> >     gm(*ParseDate.parsedate(s))
> >   end
> > end
> > 
> > and then make the default be a MyTime instead of a Time.
>  
> Yes, that would work, and be a pain. My thought is that if
> #from_s was
> integrated into Ruby, we wouldn't have this problem. The
> parsing functionality
> would be built into the Time class.

Maybe I just picked the wrong functionality for Time.from_s.

> But even so, there will always be cases like those above, but
> with different
> classes. Is there a way to handle them in an aesthetically
> pleasing way?

You'll also find just as many holes when trying to use obj.to_s
to convert an object to a string.  Sometimes it isn't going to
do it like you want.  You could argue that we don't need any
convention for #to_* methods based on that.  I think some
convention for specifying default ways to go to and from
another specific class is a good thing.  Preferrably those
methods could take optional arguments to modify the behavior. 
Or just have additional methods.

If you have a better idea I'm listening.  I just proposed about
the simplest way convert from an specific type to an arbitrary
type (#to_* provides arbitrary type to specific type).  There
have been other solutions for going from arbitrary to
arbitrary, but I have yet to see an application for that.


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