Re: return MyClass.new vs self.type.send :new

Hi --

On Sun, 10 Nov 2002, ahoward wrote:

> i've used the 'splitting a classes's methods out into a module but
> also having a concrete class' technique to create a pair called

Oh well, it sounds like we're talking about good ol' mixins.  (What's
all that 'bless' stuff? :-)

> module HTML::TableMethods
>   ...
> end
>
> clase HTML::Table < Array
>   include HTML::TableMethods
>   ...
> end
>
> you can imagine what they do...
>
> this allows me to do a database query, say
>
>   tuples = pgconn.query sql
>
> where tuples is an Array of Array of String - which in fact is how the
> postgresql lib works.
>
> tuples might be *very* large.  if tuples.size something like 30,000 rows then
> i would need to instatiate an HTML::Table and then instatiate 30,000 more
> objects to populate the table - slow.  so i thought to myself, this is a
> perfect job for a module which can then be used to extend an object on the
> fly.  after i created all the module methods i realized they work fine in a
> concreate class too... you get the picture

OK, so you're saying that, rather than populate the table with the
contents of tuples, you will add capabilities (module-wise) to tuples
itself?  Assuming that's accurate, couldn't it be as simple as:

  module TupleStuff
    ...
  end

  tuples = pgconn.query(sql)
  tuples.extend(TupleStuff)

> the end result is that one can 'cast' an object to another type on the fly -
> which can be appropriate in some circumstances.
>
> anyhow, i was just showing that you can design things so a class can be cast
> to another with some effort, whether the other class is a relative or not.
>
> you can't do that with the normal inheritence you've shown.

But you can extend any object at any time (see tuple example).  In
that sense, Ruby is designed for precisely the kind of thing you're
describing: objects born as instances of a certain class, but
extensible at run-time via modules and other techniques.  The
nativeness of this concept to Ruby is also what I was getting at
before when I said that by creating a 'bless' mechanism, and handing
around [what appeared to be] superfluous objects, you were working too
hard.

> is it actually usefull to be able to refer to child object as the
> type of it's parent.  this idiom is used all the time in c++ where
> simply pointing an appropriately typed pointer at an object you may
> access it's method as parent, child, grandchild, etc.

In Ruby, the question of type is (to one degree or another, depending
who you ask :-) subordinate to the question of an object's
capabilities and behaviors at a given point in the execution of the
program -- where those capabilities may have accrued to the object
through some combination of ancestry and/or dynamic change.  Also,
while you can get at ancestry information, there's no guarantee that
an object will behave the way its ancestors behaved....


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav