From: Stefano Crocco <stefano.crocco@...>
Date: 2007-07-24T21:55:48+09:00
Subject: Re: Ruby Basics

Alle marted狸 24 luglio 2007, Ralph Grothe ha scritto:
> Hello,
>
> I successfully compiled and installed Ruby and Gems on this HP-UX box
> (see my other thread).
>
> Yesterday, I bought a copy of the Ruby equivalent to the Perl Camel Book
> (n.b. I am coming from Perl), viz. the PickAxe Book,
> and read the first couple of chapters while toying parallel a little bit
> at the irb>
>
> That's where my first question arose.
> Being used to the Perl debugger for similar experiments like with irb,
> the former at least offers, albeit moderate, history amenities (viz.
> !cmd#, to repeat cmd No. #)
> I would have expected irb to offer some readline and thus command
> history support (I am a lousy typer)?

irb does have readline support, but it's not enabled by default. One way to do 
this is to pass the --readline option to irb (see irb -h for other options). 
According to the first version of the pickaxe (I don't have the second one), 
you should be able to do this also by setting IRB.conf[:USE_READLINE] to true 
in your .irbrc, but I'm not sure this information is up to date. Since you 
just bought the book you can look there for more information. Another 
possibility is to use wirble (http://raa.ruby-lang.org/project/wirble/).

> Then while reading the code examples in the PickAxe I was a little
> bewildered
> how the authors were merrily extending their sample classes by simply
> redifinig some method to add functionality without, as I would have
> expected,
> first sublassing the class and then overriding single methods.
>
> Instead it went like this
>
> E.g.
>
> class Noise
>   def moo
>     # some implementation
>   end
> end
>
> # more paragraphs of text
> # and then taking up again
>
> class Noise
>   def moo
>     # deviating implementation from first definition
>   end
> end
>
> # and so forth
>
>
> I this valid (and recommnded) Ruby, or were they just
> sweeping former stuff under the carpet to keep the sample code terse?

If I understand correctly your question, I'd say it's the latter.
You can't add functionality to a method by redefining it: redefining a method 
overwrites the previous definition:

class C

  def a_method
    puts "this is the first definition"
  end

  def a_method
    puts "this is the first definition"
  end

end

C.new.a_method
=> "this is the second definition"

On the other hand, you can reopen a class to add other methods or constants 
(or to redefine already defined methods):

class C

  def method_1
    puts "this is method_1"
  end

end

# some other code

class C
  
  def method_2
    puts "this is method_2"
  end

end

C.new.method_1
=> "this is method_1"

C.new.method_2
=> "this is method_2"

> Similarily, I was puzzled that it seems to be possible to
> again extend base classes like Array without being required to subclass
> and override, instead doing something like
>
> class Array
>   def my_super_sort
>     # implementation
>   end
> end
>
> Is this really all that easy?

It is, but you need to be careful. If you only want to add new methods, then 
it's most likely ok, but if you want to modify already existing methods, then 
you can get in trouble, because other libraries (including the ruby standard 
library) expect those methods to behave in a certain way and will break if 
they don't.

> As for style, shouldn't Ruby class definitions just as one
> class-end block go into a single file instead of these break ups?

Usually, a class definition is indeed a single class/end block in a single 
file. They're broken up only if there is some reason to do it.

> named as the class

Stefano