Ruby reference recommendations

ruby-talk
1

Hi, I’m new to Ruby, on my second day now, and I love the language so
far, but there’s one problem. The documentation I’ve found so far is
pretty incomplete or at least hard to find info in. Is there a real Ruby
reference out there on the web? I’ve got the Ruby manual, and I’ve
checked out the “book” at rubycentral.com, but it’s all incomplete.

For instance, what errors will File.new throw? When exactly does Ruby
pass by reference and when does it copy the object? If you return an
object from a function, does it copy that object, or does it return a
reference? If it returns a reference like I think it does, does that
provide the calling function with access to write to the returned object?

If there’s a book out there I should buy, please let me know.
rubycentral.com looks like a decent introduction to the language, but I
need something a little more solid. Thanks in advance for your
recommendations :slight_smile:

2

Hi, I’m new to Ruby, on my second day now, and I love the language so
far, but there’s one problem. The documentation I’ve found so far is
pretty incomplete or at least hard to find info in. Is there a real Ruby
reference out there on the web? I’ve got the Ruby manual, and I’ve
checked out the “book” at rubycentral.com, but it’s all incomplete.

The pickaxe book is widely considered to be the best introductory and
reference material available in English…

For instance, what errors will File.new throw? When exactly does Ruby
pass by reference and when does it copy the object?

All objects but Fixnum (and you don’t see the difference because there’s
no “mutator” methods defined in that class and you cannot define singleton
methods for it) and Float (not sure about the latter). Maybe I forget
something, but anyway, in practice, all objects.

If you return an
object from a function, does it copy that object, or does it return a
reference?

a reference

If it returns a reference like I think it does, does that
provide the calling function with access to write to the returned object?

You can use methods that modify the internal state of the object.

class Foo
def initialize
@foo = “a”
end
def foo
return @foo
end
end

a = Foo.new
puts a.foo # a
b = a.foo
b << “b”
puts a.foo # ab

If there’s a book out there I should buy, please let me know.
rubycentral.com looks like a decent introduction to the language, but I
need something a little more solid. Thanks in advance for your
recommendations :slight_smile:

If you don’t like it, you’re different from most of us :stuck_out_tongue:

···

On Tue, May 20, 2003 at 03:10:35PM +0900, Dave wrote:

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

…[Linux’s] capacity to talk via any medium except smoke signals.
– Dr. Greg Wettstein, Roger Maris Cancer Center

3

Dnia wto 20. maja 2003 08:10, Dave napisa³:

When exactly does Ruby pass by reference and when does it copy the object?

Conceptually it always passes by reference, never makes a copy.

If you return an object from a function, does it copy that object, or does
it return a reference?

Again, always a reference.

If it returns a reference like I think it does, does that provide the
calling function with access to write to the returned object?

Potentially yes. Some objects don’t provide any method which changes their
state, so in these cases there is no access to give or refuse.

I’m surprised that so many people are confused by that. Most languages, and
almost all modern languages, work like this, and the model is really simple -
there is one way to pass arguments, one way to return results, and no
implicit copying. These languages don’t include C, C++ and Pascal though.

···

–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.

4

“Marcin ‘Qrczak’ Kowalczyk” qrczak@knm.org.pl schrieb im Newsbeitrag
news:200305200935.32508.qrczak@knm.org.pl…

Dnia wto 20. maja 2003 08:10, Dave napisa³:

I’m surprised that so many people are confused by that.

Maybe part of the confutions comes from the fact that you can define =
which makes code look as if you could modify an internal reference (e.g.
in Hash).

Most languages, and
almost all modern languages, work like this, and the model is really
simple -
there is one way to pass arguments, one way to return results, and no
implicit copying. These languages don’t include C, C++ and Pascal
though.

:-)) And you have to include Java in the list - because of its primitive
types.

OT: For a complete list of the other disadvantages of this inconsistency
do a search for “Primitive Types Considered Harmful”.

robert
5

Dnia wto 20. maja 2003 12:11, Robert Klemme napisa³:

:-)) And you have to include Java in the list - because of its primitive
types.

Well, in some respects it doesn’t matter that they are represented
differently, since they are immutable. You can think about them as references
to immutable number objects. They are passed to functions and returned from
them and stored in data structures in the same way as regular objects.
Arithmetic operations always return the same object for the given value, so
== works as for references.

The only conceptual differences are when you can’t implicitly coerce them to
object class and back, that “references” to them can’t be nil, that you can’t
synchronize on them, and perhaps other things like this. And it’s bad that
identity is the “default” equivalence, which happens to work on primitive
types and mutable objects. Immutable objects should be always compared by
value - this includes immutable strings and large numbers, but in Java the
proper comparisons for them are different than for ints.

···

–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.

6

“Marcin ‘Qrczak’ Kowalczyk” qrczak@knm.org.pl schrieb im Newsbeitrag
news:200305201459.13367.qrczak@knm.org.pl…

Dnia wto 20. maja 2003 12:11, Robert Klemme napisa³:

:-)) And you have to include Java in the list - because of its
primitive
types.

Well, in some respects it doesn’t matter that they are represented
differently, since they are immutable. You can think about them as
references
to immutable number objects. They are passed to functions and returned
from
them and stored in data structures in the same way as regular objects.
Arithmetic operations always return the same object for the given value,
so
== works as for references.

True.

The only conceptual differences are when you can’t implicitly coerce
them to
object class and back, that “references” to them can’t be nil, that you
can’t
synchronize on them, and perhaps other things like this. And it’s bad
that
identity is the “default” equivalence, which happens to work on
primitive
types and mutable objects.

It does not work for mutable instances whose equivalence is state based
and not identity based.

Immutable objects should be always compared by
value - this includes immutable strings and large numbers, but in Java
the
proper comparisons for them are different than for ints.

Since there is no way in Java to define a class a having immutable
instances IMHO the approach taken in Java (and in Ruby also) is the most
reasonable one. When implementing classes that should behave like String
and Integer, i.e., equality is dependent on state and not identity, people
have to take this into consideration and override the appropriate methods
(hashCode() and equals() for Java).

In ruby we can do

module StateEquivalent
def eql?(obj)
return false unless self.class == obj.class

(self.instance_variables + obj.instance_variables).uniq.each do |var|
  v1 = self.instance_eval var
  v2 = obj.instance_eval var
  return false unless v1 == v2
end

return true

end

def ==(obj); eql? obj; end
end

(see attached script for test)

Regards

robert

equivalencer.rb (1.3 KB)

7

Dnia wto 20. maja 2003 18:53, Robert Klemme napisa³:

Since there is no way in Java to define a class a having immutable
instances

There is: just don’t provide any method which changes attributes.
A pity that an attribute can’t be exposed read-only.

IMHO the approach taken in Java (and in Ruby also) is the most
reasonable one.

The flaw in the Java approach is that there is no single operation which is
both definable for user classes (and defined for classes like string to
compare contents) and works for int (and other primitive types).

···

–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.

8

I’ve massages it a bit, added hash calculation and put it on the Wiki.

http://www.rubygarden.org/ruby?EquivalenceVsIdentity

Is there anything like this on the RAA already? If not, should I put it
there?

robert
9

“Marcin ‘Qrczak’ Kowalczyk” qrczak@knm.org.pl schrieb im Newsbeitrag
news:200305202113.47799.qrczak@knm.org.pl…

Dnia wto 20. maja 2003 18:53, Robert Klemme napisa³:

Since there is no way in Java to define a class a having immutable
instances

There is: just don’t provide any method which changes attributes.
A pity that an attribute can’t be exposed read-only.

Well, but this is no strict class level declaration (like “abstract” is)
that could be used to automatically detect immutability of a class. In Java
a compiler could evaluate all fields and if they are final assume
immutability. But then there’s still inheritance… In Ruby I guess it
would be more complicated, because the code of a class can change all the
time.

IMHO the approach taken in Java (and in Ruby also) is the most
reasonable one.

The flaw in the Java approach is that there is no single operation which
is
both definable for user classes (and defined for classes like string to
compare contents) and works for int (and other primitive types).

Yepp!

robert