Re: Managing metadata about attribute types

On Wed, 5 Nov 2003 23:52:49 +0900
Richard Kilmer <[e-mail]> wrote:

> On Nov 5, 2003, at 4:08 AM, Ryan Pavlik wrote:
> 
<snip>
> > 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.

Right, but each string in XML is representative of a general desired
type.  This seems to trivialize the problem, but it doesn't---it's
still the same problem; you just expect String to have a conversion
type for every known class.

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

As above, this isn't really the case.  You could write a proc for
every attribute, every time you need it, but this is rather ugly.
You could reuse procs to avoid some code duplication.  I did propose a
similar type conversion system awhile back that would allow this, but
it never seemed to take off.

Also, in this case, (and unlike the independent conversion mechanism),
it still requires your class to know how to convert each type into the
desired type.

Finally, since Austin is _proposing_ this as a generalized solution to
these problems, it should be considered in a general light.  It
doesn't even really work for just strings.

<snip>
> > Using #to_* methods are the ruby equivalent of type casting.  The
> 
> I disagree.  to_* is not type casting, its duck typing.

This is just a cutesy name for doing the same thing.  In C++, I could
write things the same way, explicitly doing a cast to my desired type
everytime I want it.

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

Actually, I would argue that this is _not_ duck typing.  This is
explicitly asking for a type: string, float, etc.  Duck typing is
treating the type as duck you want, without explicitly referring to
type.

But calling #to_* methods is explicitly converting ("casting") one
type to another.  It's just less formal and less general (since in C++
you can at least define operator-Type for explicit conversions).

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

Well, in my case, #respond_to? is insufficient information.  (My other
argument against it is that it doesn't tell me semantically what the
method does, if it's actually going to quack, so to speak, or if it's
just a duck-billed platypus.)

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

It makes sense.  However, the way I program, the Class _is_ the
definition of a behavioral set.  This is highly important, and results
in a lot of benefits.

As above, checking #respond_to? doesn't actually guarantee that your
method set is actually the behavioral set you desire.

(Yes, I'm fully aware you can modify classes and break things so that
things behave differently in the same class.  There is no reason to do
this.  However, on the flip side, you cannot guarantee that every
given method #N has the same semantic identity across every class
without severely restricting your functionality.)

-- 
Ryan Pavlik <[e-mail]>

"Do not question wizards, for they are quick to
 turn you into a toad." - 8BT