Forum: Ruby Ruby Basics

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cf21df4052f758015fbaec6e5c3e34e8?d=identicon&s=25 Ralph Grothe (deadwood)
on 2007-07-24 14:26
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)?

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?

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?

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

named as the class
A8486651a974d7d9ecc35d25de96c7ee?d=identicon&s=25 Chris Lowis (chrislo)
on 2007-07-24 16:06
> I would have expected irb to offer some readline and thus command
> history support (I am a lousy typer)?

You can get command history by installing the wirble gem

  sudo gem install wirble

and adding the following to your ~/.irbrc file

  # load libraries
  require 'rubygems'
  require 'wirble'

  # start wirble (with color)
  Wirble.init
  Wirble.colorize

More information on wirble here :
  http://pablotron.org/software/wirble/

> Is this really all that easy?

My understanding is that it is this easy !

You might also find the following interesting :
http://www.ruby-lang.org/en/documentation/ruby-fro...

Regards,

Chris
Cf21df4052f758015fbaec6e5c3e34e8?d=identicon&s=25 Ralph Grothe (deadwood)
on 2007-07-24 16:27
Chris Lowis wrote:
>> I would have expected irb to offer some readline and thus command
>> history support (I am a lousy typer)?
>
> You can get command history by installing the wirble gem
>
>   sudo gem install wirble
>
> and adding the following to your ~/.irbrc file
>
>   # load libraries
>   require 'rubygems'
>   require 'wirble'
>
>   # start wirble (with color)
>   Wirble.init
>   Wirble.colorize
>
> More information on wirble here :
>   http://pablotron.org/software/wirble/
>
>> Is this really all that easy?
>
> My understanding is that it is this easy !
>
> You might also find the following interesting :
> http://www.ruby-lang.org/en/documentation/ruby-fro...
>
> Regards,
>
> Chris


Hi Chris,

many thanks for the quick response and the valuable hint for the wirble
gem.
As I have to leave now, it will be the first thing that I try tomorrow
and give feedback.

As for Gems configuration.
Do you have any idea where and how I would have to put our proxy
informations (url, port, credentials) so that I could query Internet
Gems repositories?
I tried the -p http://proxy_user:proxy_passwd@our.proxy.url:proxy_port
switch with the gem list command but it didn't work.
So I sought for a config file like I am used to with the Perl
CPAN/Config.pm
but couldn't find something comparable beneath the gems tree.

I start to like Ruby.
I only need to get used to Ruby idioms and doing things the Ruby way
instead of taking over habits from Perl.
But since I so far lack knowledge of all the methods
(although some_object.methods.sort in irb is a tremendous help) it takes
some
time to discover.
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2007-07-26 00:45
(Received via mailing list)
On 7/24/07, Ralph Grothe <ralph.grothe@itdz-berlin.de> wrote:
> Hello,

<snip>

> 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)?

It should.  Did you compile with readline (you need to have
lib-readline of course).

>
>   def moo
> 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?

Yes, but as in all easy things, there are caveats.

You can 'open' up any class, and, in fact, any object whenever you want.

irb> a = "hello"
=> "hello"
irb> b = "hajimemashite"
=> "hajimemashite"
irb> a.class
=> String
irb> b.class
=> String
irb> class String; def welcome_f; puts self + ", welcome to f method!";
end; end
=> nil
irb> a.welcome_f
hello, welcome to f method!
=> nil
irb> b.welcome_f
hajimemashite, welcome to f method!
irb> def a.welcome_g; puts self + ", welcome to g method!"; end; end
=> nil
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 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.

hth a little,
Todd
C40020a47c6b625af6422b5b1302abaf?d=identicon&s=25 Stefano Crocco (crocco)
on 2007-07-26 00:46
(Received via mailing list)
Alle martedì 24 luglio 2007, Ralph Grothe ha scritto:
> 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/).

>
>   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"

> 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
Cf21df4052f758015fbaec6e5c3e34e8?d=identicon&s=25 Ralph Grothe (deadwood)
on 2007-07-26 12:46
Stefano Crocco wrote:
> Alle martedì 24 luglio 2007, Ralph Grothe ha scritto:
>> 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/).
>

Hi Stefano,

I fear my ruby build on hpux doesn't currently contain readline support
because I wasn't aware that I obviously was required to signal make that
I wished so.
When I start irb with --readline it doesn't seem to show any effect
(e.g. promoted tab completion or command history missing)
Although I am a lucky owner of the 2nd ed. of Pickaxe (which cover Ruby
1.8)
I haven't yet come accross every chapter despite occassional flipping
(it's such a tome)
In my volume chpt. 15 deals on IRB, but I haven't yet fumbled up a
$HOME/.irbrc
let alone hacked the IRB class.

How can I verify if my ruby build lacks or supplies readline support?

I came accross that Config module (btw, Perl has a namesake which
imports per default (I see Rubyists frown upon such namespace pollution)
a tied hash called %Config).
So I hoped to find, case ignoring, any key that hopefully somewhat
intuitively named by this module's author could contain the string read.
But this futile attempt doesn't hit:

$ ruby -r rbconfig -e 'include Config;puts
CONFIG.keys.grep(/read/i).sort.join("\n")'

Btw, not having delved into the Modules chapter yet,
why am I supposed to require *and* include here?


> 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:

Well, I am by far no OO expert, and Perl's OO implementation
of OO is very liberal indeed for the Purists' taste.

But redefination of a method from a derived class is actually what you
do,
if you aren't please with its functionality, so I thought.
While those methods you are happy with you simply inherit.


>
> class C
>
>   def a_method
>     puts "this is the first definition"
>   end
>
>   def a_method
>     puts "this is the first definition"
>   end

I asume a typo here,
you probably meant "this is the  second definition"?

>
> 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):


Well, I think what confused me is the "strange" terminology.
I simply didn't know the concept of "reopening a class".

>
> 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"
>
>> 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.

I won't be doing this, at least for quite some while until I
master Ruby enough (will I ever?).
Cf21df4052f758015fbaec6e5c3e34e8?d=identicon&s=25 Ralph Grothe (deadwood)
on 2007-07-26 13:16
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.


> 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.

> irb> a = "hello"
> => "hello"
> irb> b = "hajimemashite"
> => "hajimemashite"
> irb> a.class
> => String
> irb> b.class
> => String
> irb> class String; def welcome_f; puts self + ", welcome to f method!";
> end; end
> => nil
> irb> a.welcome_f
> hello, welcome to f method!
> => nil
> irb> b.welcome_f
> hajimemashite, welcome to f method!
> irb> def a.welcome_g; puts self + ", welcome to g method!"; end; end
> => nil

I can't find the opening class statement that seems to belong to the the
2nd "end".
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"?
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?).

> 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.

>
>> 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)
Cf21df4052f758015fbaec6e5c3e34e8?d=identicon&s=25 Ralph Grothe (deadwood)
on 2007-07-26 13:29
Here's the full contents of the Config hash of my Ruby installation:

$ ruby -r rbconfig -e 'include Config;CONFIG.sort.each {|k,v| printf("%s
=> %s\n",k,v)}'

ALLOCA =>
AR => ar
ARCHFILE =>
ARCH_FLAG =>
AS => as
ASFLAGS =>
CC => /opt/ansic/bin/cc
CCDLFLAGS =>  +Z
CFLAGS => -g
COMMON_HEADERS =>
COMMON_LIBS =>
COMMON_MACROS =>
CP => cp
CPP => /opt/ansic/bin/cc -E
CPPFLAGS =>
CPPOUTFILE => -o conftest.i
DESTDIR =>
DLDFLAGS =>  -E
DLDLIBS =>  -lc
DLEXT => sl
DLEXT2 =>
DLLWRAP =>
ECHO_C => \\c
ECHO_N =>
ECHO_T =>
EGREP => /usr/bin/grep -E
ENABLE_SHARED => no
EXEEXT =>
EXPORT_PREFIX =>
EXTOUT => .ext
EXTSTATIC =>
GNU_LD => no
GREP => /usr/bin/grep
INSTALL => /opt/imake/bin/install -c
INSTALL_DATA => /opt/imake/bin/install -c -m 644
INSTALL_PROGRAM => /opt/imake/bin/install -c
INSTALL_SCRIPT => /opt/imake/bin/install -c
LDFLAGS =>
LDSHARED => ld -b
LIBEXT => a
LIBPATHENV => SHLIB_PATH
LIBPATHFLAG =>  -L"%s"
LIBRUBY => libruby-static.a
LIBRUBYARG => -lruby-static
LIBRUBYARG_SHARED =>
LIBRUBYARG_STATIC => -lruby-static
LIBRUBY_A => libruby-static.a
LIBRUBY_ALIASES => libruby.so
LIBRUBY_DLDFLAGS =>  -E
LIBRUBY_LDSHARED => ld -b
LIBRUBY_SO => libruby.so.1.8.6
LIBS => -ldld -lcrypt -lm
LINK_SO =>
LN_S => ln -s
MAINLIBS =>
MAJOR => 1
MAKEDIRS => mkdir -p
MAKEFILES => Makefile
MANTYPE => man
MINIRUBY => ./miniruby
MINOR => 8
NM =>
NROFF => /usr/bin/nroff
OBJDUMP =>
OBJEXT => o
OUTFLAG => -o
PACKAGE_BUGREPORT =>
PACKAGE_NAME =>
PACKAGE_STRING =>
PACKAGE_TARNAME =>
PACKAGE_VERSION =>
PATH_SEPARATOR => :
PREP => miniruby
RANLIB => ranlib
RDOCTARGET =>
RM => rm -f
RPATHFLAG =>
RUBYW_INSTALL_NAME =>
RUBY_INSTALL_NAME => ruby
RUBY_SO_NAME => ruby
RUNRUBY => ./miniruby $(srcdir)/runruby.rb --extout=.ext --
SET_MAKE =>
SHELL => /bin/sh
SOLIBS =>
STATIC =>
STRIP => strip
TEENY => 6
TRY_LINK =>
WINDRES =>
XCFLAGS =>  -DRUBY_EXPORT
XLDFLAGS =>  -Wl,-E -L.
YACC => bison -y
YFLAGS =>
arch => hppa2.0w-hpux11.11
archdir => /usr/local/lib/ruby/1.8/hppa2.0w-hpux11.11
bindir => /usr/local/bin
build => hppa2.0w-hp-hpux11.11
build_alias =>
build_cpu => hppa2.0w
build_os => hpux11.11
build_vendor => hp
configure_args =>  '--with-zlib-dir=/opt/iexpress/zlib'
'--with-openssl-dir=/opt/openssl/0.9.7' 'CC=/opt/ansic/bin/cc'
datadir => /usr/local/share
datarootdir => /usr/local/share
docdir => /usr/local/share/doc/$(PACKAGE)
dvidir => /usr/local/share/doc/$(PACKAGE)
exec_prefix => /usr/local
host => hppa2.0w-hp-hpux11.11
host_alias =>
host_cpu => hppa2.0w
host_os => hpux11.11
host_vendor => hp
htmldir => /usr/local/share/doc/$(PACKAGE)
includedir => /usr/local/include
infodir => /usr/local/share/info
libdir => /usr/local/lib
libexecdir => /usr/local/libexec
localedir => /usr/local/share/locale
localstatedir => /usr/local/var
mandir => /usr/local/share/man
oldincludedir => /usr/include
pdfdir => /usr/local/share/doc/$(PACKAGE)
prefix => /usr/local
psdir => /usr/local/share/doc/$(PACKAGE)
ruby_install_name => ruby
ruby_version => 1.8
rubylibdir => /usr/local/lib/ruby/1.8
rubyw_install_name =>
sbindir => /usr/local/sbin
setup => Setup
sharedstatedir => /usr/local/com
sitearch => hppa2.0w-hpux11.11
sitearchdir => /usr/local/lib/ruby/site_ruby/1.8/hppa2.0w-hpux11.11
sitedir => /usr/local/lib/ruby/site_ruby
sitelibdir => /usr/local/lib/ruby/site_ruby/1.8
sysconfdir => /usr/local/etc
target => hppa2.0w-hp-hpux11.11
target_alias =>
target_cpu => hppa2.0w
target_os => hpux11.11
target_vendor => hp
topdir => /usr/local/lib/ruby/1.8/hppa2.0w-hpux11.11
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2007-07-26 13:38
(Received via mailing list)
2007/7/26, Ralph Grothe <ralph.grothe@itdz-berlin.de>:
> Yes, but don't Rubyists promote a certain style guide?
> (Perlists are pretty picky about it, contrary to the language's public
> conception)

Well, there are *some* style rules but not with respect to how many
times you open and close classes.  Actually there are cases (i.e. when
modifying lib classes like String etc.) where it is the only realistic
option to open it in your script and add a few methods.

Kind regards

robert
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2007-07-26 15:18
(Received via mailing list)
On 7/26/07, Ralph Grothe <ralph.grothe@itdz-berlin.de> wrote:
> please see my response to Stefano's reply.
Look at your mkmf.log file at <ruby build
directory>/ext/readline/mkmf.log

> 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.

> > 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
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2007-08-02 13:50
(Received via mailing list)
On 7/26/07, Todd Benson <caduceass@gmail.com> wrote:
> On 7/26/07, Ralph Grothe <ralph.grothe@itdz-berlin.de> wrote:
> >
> > 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".

My bad!  The second "end" for the second "def" statement is a mistake!
 I thought you were asking about the first def.  My apologies.

Todd
This topic is locked and can not be replied to.