From: Gavin Kistner <gavin@...>
Date: 2005-09-14T22:05:46+09:00
Subject: Re: yet another simple command-line option parser

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?