Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-19 (18:15)
From: John Max Skaller <skaller@o...>
Subject: Re: [Caml-list] productivity improvement
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 
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.


    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,
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: