From: ahoward <ahoward@...>
Date: 2002-11-11T03:24:45+09:00
Subject: Re: return MyClass.new vs self.type.send :new

On Mon, 11 Nov 2002 dblack@candle.superlink.net wrote:

[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
[snip]

sorry, i was not clear :

i meant that for instance or class methods which returned/use objects of THAT
class one should use

  class Klass
    def method
      self.class.new
    end
  end

instead of

  class Klass
    def method
      Klass.new
    end
  end

so subclasses would exhibit similar behavior - eg. #method would return the
SAME class as the calling object.

what i'm advocating is NOT hardwiring a class name into a method.

that's it.

[snip]
> 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]

agreed.  the *single* best thing about C is that man details every thing in a
blink - so any incosistencies tend not to be too problematic.  tcl is also
smart that way (installs lots of docs/man pages).  ruby could improve here...

did you see Dave Thomas' post today about this?  cool ideas.

[snip]
> 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.
[snip]

i suppose there are reasons, but these are the exact reasons people have
claimed an interface capbility in ruby would be good... i don't know what i
think about this...  it IS nice to be able (at compile time) to guarantee that
an object implements method 'x' - but hardly essential IMHO.  tha's another
can of worms entirely

[snip]
> And there are other cases, too, like #to_s, where one might well want to
> start from scratch.
[snip]

i personally never do this since it violates the ISA relation amongst
parents/chilren.  eg. if something ISA Klass (via inheritence), you should be
able to use it everywhere one can use a real Klass object otherwise it ISNOTA
Klass... see what i mean?  it's just a personal thing mind you - i'm not
advocating it for anyone else...

[snip]
> 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).
[snip]

rules are made to be broken.

i guess i'm just suggesting a module/class style FAQ... nothing more strict than
that.  ;-)

-a

-- 

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328
 | Email: ahoward@fsl.noaa.gov
 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================