Ten Things Every Java Programmer Should Know About Ruby

ruby-talk
1

Lähettäjä: Navindra Umanee <navindra@cs.mcgill.ca>
Aihe: Re: Ten Things Every Java Programmer Should Know About Ruby

> You're exactly right. Ruby is /strongly/ typed, meaning that each
> object is of a discrete, well-defined type, but it is not strictly

No offense, but I never said anything of the sort... :slight_smile:

I don't know what the definition of type in Ruby is, but as far as I
can tell it is anything but discrete. Types overlap inasmuch as the
method names they respond to overlap. It really only seems to make
sense to talk about methods and not to get hung up on types.

It is discrete. A given object at a given time has a discrete,
complete and well-defined type. I agree on the latter part, though;
thinking in terms of Java types and variables will get you in trouble.

<warning>

A "biggest" type in Ruby (that is, a type that can pass for almost any
type) is probably the object that implements all methods, or simply,
method_missing. However there can be different implementations of
method_missing, and so matters get very murky indeed because the
behaviour of two different biggest types by this definition can be
very different. Probably the biggest *biggest* type is an object that
implements all methods and returns itself each time. Even then it
might not always quack like a duck.

</warning>

It really isn't too clear. :slight_smile:

> Well, Ruby does guarantee that you can't call 'foo' on an object that
> doesn't implement that method.

Yes... foo and method_missing.

If method_missing handles 'foo', then the object responds to 'foo'.
'Type safety', as matz-ue specifies it, simply means that any
attempt at invoking a method on a receiver will be caught at runtime
(just like Java).

> No, a label for a Socket object (e.g. 'foo' in 'foo = Socket.new') may
> point to a different type of an object. The object itself doesn't
> change. This is a really important bit.

I hope we can stop talking about variables... please see the example
code I have given in the other emails where an object changes its
type.

The object doesn't change its type. The variable you're dealing with
changes its type :slight_smile: If an object's class is modified at runtime (e.g.,
adding a method to Hash), then you may consider its type having been
changed (if you think of the object's type to be the combination of
attributes and methods it has rather than the class name).

Now, I certainly understand what you're saying. It seems that you
may need to pay extra attention to get the types right without the
compiler support that some other languages give you but this is
usually not a big problem in a well-designed program. I, personally,
am yet to run into a type program like you described in any of my
projects. Forget all you know and go with the flow etc. :slight_smile:

Cheers,
Navin.

E

···

E S <eero.saynatkari@kolumbus.fi> wrote:

2

Hi --

If method_missing handles 'foo', then the object responds to 'foo'.

That's true in an informal sense, but it doesn't capture the practical
relation between #respond_to? and #method_missing -- which is that
#method_missing is what happens to messages that don't correspond to
what the object #respond[s]_to? In other words, one can say that an
object responds to every message, and that no method is truly missing,
but that isn't the whole story of the #respond_to?/#method_missing
mechanisms.

I think it's better to think of it as: an object responds to a certain
set of messages, and if it's sent a message it doesn't respond to,
that's considered an exceptional condition which can be trapped either
with a rescue clause or with the special #method_missing method.

David

···

On Sun, 30 Jan 2005, E S wrote:

--
David A. Black
dblack@wobblini.net