> Lähettäjä: Navindra Umanee <navindra@cs.mcgill.ca>
> Aihe: Re: Ten Things Every Java Programmer Should Know About Ruby
>
> E S <eero.saynatkari@kolumbus.fi> wrote:
> > 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... :-)
>
> 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. :-)
>
> > 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 :) 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. :)
> Cheers,
> Navin.
E