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

Hi --

On Sun, 10 Nov 2002, ahoward wrote:

> On Mon, 11 Nov 2002 [e-mail] wrote:
>
> [snip]
> > But what exactly would that mean in this case?  Does every method of
> > every class have to return an object of that class?
> [snip]
>
> i don't understand this conclusion?

Let's say you have:

  class Thing < String
    def greeting
      "Hello"
    end
  end

Thing#greeting returns a String.  If I'm understanding your argument
correctly, you would advocate something like:

    def greeting
      self.class.new("Hello")
    end

But I think that's overkill.  The fact that Child inherits from Parent
does not (I would argue) mean that no instance method of Child should
ever return a Parent object.

> surely there must be some good 'rules of thumb' for this problem set.  i've
> suggested some of my own which, while restrictive, have helped me build
> reliable libraries in C and C++.  surely the principles are not all that
> different - ruby cannot do anything C can't after all.  ;-)

Well, I guess you could say a violin can't do anything a tree can't,
but that doesn't mean you'd look to the field of forestry to figure
out how best to use your violin :-)

I tend to think too that documentation plays a role in some of this.
If I'm inheriting from Thing (see above), and the docs for
Thing#greeting indicate that the return value is a string, then I'm
aware of what's going on.

> [snip]
> > For example, if the super method consists of 'raise "Not implemented!"', you
> > probably don't want to call it :-)
> [snip]
>
> this specific problem deals with designing interfaces - which are
> not directly supported in ruby - so it's not really a fair
> objection.  the only reason for doing the above is to catch what the
> compiler cannot.  if a method were purely virtual then extending it
> would imply creating one in the first place and 'super' would, of
> course, not make sense.

I agree that this practice (writing modules with stub methods) does
not map directly onto the notion of interfaces in other languages, as
I understand them (which is very little) -- but still, there's no
reason it shouldn't be used to organize a program in Ruby, even if
it's at the expense of universality in the matter of using 'super' in
overridden methods.  And there are other cases, too, like #to_s, where
one might well want to start from scratch.

Mind you, I'm not advocating chaos, nor suggesting that everything
that can be done should be done.  I'm just not sure it pays to make
broad up-front decisions about some of these things (nor that it's
practicable).


David

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