Alessandro Baretta wrote:

>
> Yes, but RTTI is a hack. 


Matches on ocaml unions _also_ use run time checks.

> Nobody would seriously "plan" to use RTTI during the design stage of a 
> software system. 

Sure they do.

> You just "happen" to need RTTI when most of the code is already there 
> and you realize there is a bug in the specification which would 
> require to redesign the inheritance hieararchy. In such cases you go 
> with RTTI. Otherwise, you'd stick to simple OO polymorphism, which is 
> the "Right Way(TM)" to use 


No. (class based) object orientation is utterly flawed as a paradigm, as 
can be seen
by posing the trivial problem of representing any type with a binary 
operator.
It just can't be done, the problem is called 'covariance problem'.

I find it hard to state what the problem is here, but I'll try:
the problem is you can write an unimplementable interface
and not get a type error:

    struct X { virtual bool binop(X const&)const=0; };

No (realistic) instances of this class can be constructed
because no derived class can implement the method binop.
[That is a fact not to be debated] The problem then is that
you can reasonably expect to write this interface for
say a 'number' type.

In commerical applications, almost ALL data is relational,
and so cannot be abstracted. The OO paradigm is not just
useless here, but downright destructive.

Example:

    class Transaction { ..
    class Invoice { ...

Well, suppose you wanted more than one kind of transaction,
and more than one kind of invoice .. some ignorant designer
would think polymorpism would work here.

I doesn't though. You you end up using RTTI hacks,
NOT because of a design error .. but because the very paradigm
is faulty.

Not I'm not saying objects/classes etc are useless. I'm saying
they're just a tool with some limited uses: they perform well
when restricted to those uses. If no covariant methods are needed,
abstraction works. For example: device drivers typically have
methods with invariant arguments.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners