On Nov 5, 2003, at 4:08 AM, Ryan Pavlik wrote:

> On Wed, 5 Nov 2003 16:13:37 +0900
> Austin Ziegler <austin / halostatue.ca> wrote:
>
> <big snip>
>> It isn't inferior, and you don't need type info. Remember -- an
>> object should validate or transform its own data.
> <big snip>
>
> I'm trying to stay out of this because I mostly disagree.  This
> however warrants addressing.

I as well have tried to stay out of this but...

>
> This is demonstrably wrong.  An object cannot validate and transform
> its own data in this context in any reasonably general manner.  It's
> simple when you're addressing a few basic types... String, Float,
> Integer, Hash and Array.
>
> This isn't general, though.  What if I want a Foo, and you give me a

What is fascinating is that the original request is not seeking a 
general
manner. Everything that comes from XML is a String...period, so to 
transform
a String into something you expect (if possible) can be done.

> Bar?  Foo was from one module (which shouldn't know about Bar), and
> Bar was from another module (which shouldn't know about Foo).  There

Again, this is a strawman.  Simon's requirement is to deal with Strings
being parsed into valid attributes of objects.  Austin's 'proc based'
approach is a nice way to do this.  Its funny, because we do not have a
problem as developers (for debugging purposes, etc) having a to_s
method on our classes...if we also had a 'from_s' class method on all of
our classes we could round-trip XML quite nicely.

> is there no #to_foo (which may be fortunate depending on your
> culinary preferences).  This leaves us with only a few options:
>
>    *  We just don't allow it.  This does no good for us.
>
>    *  We convert through an intermediary type.  This is inefficient
>       and may lose data or not work, either.
>
>    *  We decide the approach is wrong and do something else.
>
> Using #to_* methods are the ruby equivalent of type casting.  The

I disagree.  to_* is not type casting, its duck typing.  You actually
care less about the type of thing you are dealing with and more the
behavior of the thing you are given.  In this instance, to_i is the
behavior you want and you expect it to return an Integer.  The "type"
of thing you are given is not relevant, but its ability to understand
the message (to_i) is.  After coming from Java I found myself doing
lots of "kind_of?" checking on parameters, now I do many more
"respond_to?" if I care to do checks in my class to return a specific
error message.

> point in this case is not to _convert_ types, it's to provide the
> right type in the first place.  Instead of giving the attribute a

This goes beyond just setting attributes.  Many methods need parameters
that are not simply attr_accessor methods.  Those parameters are
going to be an object.  The question is whether you write your methods
to expect a certain "namespace" (Class/Module), or just simply a set
of behaviors.

I hope this makes sense.

> string and expecting it to be parsed, we want to create the desired
> type and hand that off.
>
> It has nothing to do with the #attr= function.  Strict type checking
> at that point is merely a convenience.  It's all about getting the
> input into a useful format without writing n^2 functions (for n
> classes).  This is the primary reason I wrote StrongTyping in fact;
> the strict checking has merely helped with debugging a whole lot.
>
> -- 
> Ryan Pavlik <rpav / mephle.com>
>
> "Do not question wizards, for they are quick to
>  turn you into a toad." - 8BT
>
>