]> 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