"Eric Jacoboni" <jaco / teaser.fr> wrote in message
news:863d8ntt5p.fsf / titine.fr.eu.org...

> That's exactly my problem : A is a subset of B. A subset of objects: a
> A object is always a B object, the opposite is not necessary true. My
> first post was about the lack of this concept in Ruby: dynamic typing

In a strongly type language, you very often end up creating a reference to a
base class that is common between all possible objects.
class Person
{
};
class Employee : public Person
{
};
class Manager : public Employee
{
};

// database of contacts
Person *FindName(char *name); // defined else were
Person *person = FindName("George");

Manger *manager;
manager = (Manager*)person; // might go terribly wrong

C++ is strongly type, but you often end up using unprecise types, that is
baseclasses, because you don't have enough information.
In C++ you have runtime type information as a late addon, but you don't
really know much about your data.
I C# and Java almost everything is objects, and you get type cast exceptions
all over the place. All collection classes tend to store object references
and know nothing about the actual type.

In Ruby you do not have types on the variables, but the language will always
detect when you do something senseless with the type you are actually
storing.
Therefore, I will argue that for practical purposes, Ruby has at least as
much type safety as many conventionally strongly typed languages. At least
when dealing with non-trivial object hierarchies.

It is in the nature of object orientedness. You don't know about the object.
The object knows something about itself which you do not have to care about.
In many of the places where you really exploit object oriented principles in
C++, you end up working on a baseclass, essentially mixing the types just as
much as in your original example.

Now I do believe in strong typechecking but I have too often seen the
practical benefits go up in smoke by the use of variants and the need for
only storing base class references.

MikkelFJ