From: dblack@...
Date: 2003-11-06T06:53:26+09:00
Subject: Re: Managing metadata about attribute types

Hi --

On Thu, 6 Nov 2003, Ryan Pavlik wrote:

> On Wed, 5 Nov 2003 23:52:49 +0900
> Richard Kilmer <rich@infoether.com> wrote:
>
> > On Nov 5, 2003, at 4:08 AM, Ryan Pavlik wrote:
> > > 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.

Cutesy, perhaps, but not the same as type casting.  For one thing, a
#to_* method, if it's polite, returns a new and separate object, which
then exists alongside of and independently of the object whose to_*
method returned it.

[...]

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

Nothing guarantees that -- neither #respond_to? nor #is_a?
#respond_to? gets you a little closer, because it takes care of one of
the two things for which there is no guarantee (existence of method
and behavior of method), whereas #is_a? pertains to neither.  But
every time you call a method in Ruby, there's that flashpoint where
the object either does what you want or not.  It's the (usually small)
risk connected with the (large) reward of Ruby's dynamism.

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

Maybe I'm misunderstanding your point, but if you modify a class, all
instances of that class will reflect the modification (unless they
override it on a singleton basis):

  irb(main):005:0> class A; def x; 1; end end
  => nil
  irb(main):006:0> a = A.new; a.x
  => 1
  irb(main):007:0> class A; def x; 2; end; end
  => nil
  irb(main):008:0> a.x
  => 2

Of course the thing one probably wants to do is to modify classes and
*not* break things :-) which is what singleton classes allow you to
do.  (See?  Matz thought of it already :-)  #extend is lovely, because
it sandboxes things rather effectively and lets you do nice modular
design.  For example, I've got a program where I need a CGI object
with extra capabilities.  Originally I subclassed CGI, but that broke
something (I think CGI must be particular about the return value of
#class, or something -- I didn't dig deeply to find it).  So now I've
got a module with which I extend my CGI object, and I actually like
that better.  It's nice and clean, and keeps things tailored closely
to the immediate needs of the objects.


David

-- 
David Alan Black
home: dblack@wobblini.net        # New email address
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav