> Lähettäjä: Navindra Umanee <navindra@cs.mcgill.ca>
> Aihe: Re: Ten Things Every Java Programmer Should Know About Ruby
>
> Florian Frank <flori@nixe.ping.de> wrote:
> > Ruby isn't statically type checked isn't anything new. Variables don't
> > have a type in Ruby, so you can rebind a variable to as many objects as
> > you wish like for example in Scheme.
>
> You can accomplish nearly the same thing in Java by declaring
> variables to be of type Object -- but of course it's still
> strongly-typed.
>
> An object in Java is typed according to its class definition and its
> place in the hierarchy. If you try to do something with an object,
> you must specify which type you are expecting and you must respect
> that definition as well as the actual type of the object. That's type
> safety by your definition.
>
> > If I use "strongly typed" I mean that the language is type safe: There
> > can never be an operation, that is applied to the wrong type. If you try
> > this in Ruby (or Java), an exception is raised (because of dynamic type
> > checking). So Ruby is type safe, and how I understand the phrase,
> > "strongly typed". If you don't agree, try to define "strong typing" in
> > another meaningful way.
>
> As far as I can tell and what all the examples seem to have shown, is
> that Ruby doesn't really have a strict concept of type as most people
> understand it.
You're exactly right. Ruby is /strongly/ typed, meaning that each
object is of a discrete, well-defined type, but it is not strictly
typed in the sense that a variable may hold different types and
a type need not be specified to invoke an operation on an object.
strong/weak = Does the language have discrete types for all objects.
strict/loose = Does the language require type specifiers etc.
Conceptually you should really treat everything as an object: tell
it to do something and see what happens. If you've constructed your
software well, what happens will be what you expected to happen. In
place of things like 'public void foo(type a, otherType b)', you use
run-time reflection, unit testing and overall good engineering :)
> Okay, so object.class will supposedly tell you what class an object
> is... but you can override that method and nobody really cares. So
> Ruby doesn't guarantee anything about type safety.
Well, Ruby does guarantee that you can't call 'foo' on an object that
doesn't implement that method.
> All Ruby cares about is that an object responds to the method that is
> being called on it -- however that object may respond and whatever
> type the object may be is irrelevant.
>
> object.fly() may cause a bird to fly or a pig to eat a fly. It
> doesn't matter. You can of course do the same thing in Java, but you
> have to do it by respecting types i.e. you pretty much have to know
> what you are doing to accomplish this.
>
> An object in Ruby may even change its type from one moment to the
> other. A Socket object may suddenly become a File object.
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.
(Technically it's also possible to modify the Class Socket to
essentially become Class File, but that'd be stupendously poor
design.)
> Duck typing seems the best description so far for what Ruby does. I
> think it really confuses the issue to say that Ruby has strong typing
> in addition to duck typing... unless I'm missing something, which is
> very much possible.
>
> > An example for a type unsafe or weakly typed language would be C, where
> > bad things can happen because of it:
> >
> > (flori@lambda:c 0)$ cat foo.c ; make foo; ./foo
> > main() { printf("%s\n", 666); }
> > Segmentation fault
>
> I agree this is weak typing.
>
> Cheers,
> Navin.
E