On 7/26/07, Ralph Grothe <ralph.grothe / itdz-berlin.de> wrote:
> Todd Benson wrote:
> > On 7/24/07, Ralph Grothe <ralph.grothe / itdz-berlin.de> wrote:
> >> Hello,
> >
> > It should.  Did you compile with readline (you need to have
> > lib-readline of course).
> >
>
> Hi Todd,
>
> please see my response to Stefano's reply.

Look at your mkmf.log file at <ruby build directory>/ext/readline/mkmf.log

>
>
> > Yes, but as in all easy things, there are caveats.
> >
> > You can 'open' up any class, and, in fact, any object whenever you want.
> >
>
> This "opening" sounded rather unfamiliar to me.
>
> I can't find the opening class statement that seems to belong to the the
> 2nd "end".

First "end" is for the "def".  Second "end" is for the "class".

> Or is irb so forgiving?
> But interesting here seems to be that you explicitly specify the object
> "a" as "receiver" in your definition of method welcome_g.
> Is this what makes it a "singleton"?

Sort of.  It makes the method a singleton method, and makes "a" an
instance of a singleton.  At least, that's the way I understand it.

> I haven't yet read enough about this concept.
> In some way it looks to me as some sort of privatizing data an methods
> to a certain object (what sets it apart from the "private" protector?).

"private" just restricts access of methods to solely the object.  As
you can see, there is no restriction with the welcome_f or welcome_g
methods.  If they were private, my attempt to call them would raise an
error.

>
> > irb> a.welcome_g
> > hello, welcome to g method!
> > => nil
> > irb> b.welcome_g
> > NoMethodError: undefined method 'g' for "hajimemashite":String
> >
> > The welcome_g method for the object a is called a singleton method.
> > It applies only to a.
> >
> > There are obvious risks in opening up core classes (like String),
> > especially if you modify them instead of just adding to them.  Even
> > adding to classes after the fact is somewhat dangerous because of
> > possible clashes with gems that you use, or sometimes even with your
> > own code!
>
> As already replied to Stefano,
> it will certainly take quite a while until I would be confident enough
> to mess about with core classes.

Mess away.  You won't permanently hurt anything (unless you ditribute
your code to some unwary users, of course :).

As for style, a general rule of thumb is that you don't open already
defined classes, and if you do, it's usually to add functionality, not
modify it.

>
> >
> >> As for style, shouldn't Ruby class definitions just as one
> >> class-end block go into a single file instead of these break ups?
> >
> > That's almost certainly up to you.
>
> Yes, but don't Rubyists promote a certain style guide?
> (Perlists are pretty picky about it, contrary to the language's public
> conception)

If you are worried about style, just look at some code from the RAA
site or the rubyforge site for examples.

cheers,
Todd