]> John Max Skaller wrote: > Alessandro Baretta wrote: > >> >> Yes, but RTTI is a hack. > > > > Matches on ocaml unions _also_ use run time checks. Sure. Pattern matching is not a problem when it's idiomatic and safe. You can say that pattern matching is the most basic construct in O'Caml--even let x = 1 is a pattern matching. C++, on the other hand, has *no* pattern matching construct. RTTI is a kludge, retrofitted on a badly flawed language, because there were situations where OO polymorphism could not be used. >> Nobody would seriously "plan" to use RTTI during the design stage of a >> software system. > > Sure they do. Some people even go bungee jumping o sky diving. You just wouldn't beleive how crazy people can get. >> 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 searched Google for a covariance problem related to unimplementable interfaces but with no luck. Could you point me to some literature? > struct X { virtual bool binop(X const&)const=0; }; Tell me if I got this straight: OO polymorphism requires that inheriting classes wishing to override methods of parents must use covariant return types and contravariant parameter types, so as to guarantee that inheritance implies subtyping. In this case, it would be meaning less to implement interface X because, applying the contravariance principle to the formal parameter of binop, you'd end up with a class whose binop will accept as rhs parameters any instance of any subtype of X. Therefore a class Integer will have a greater_than_binop accepting instances of class Rational, Real, Complex, Quaternion ... This is meaningless, of course, so we conclude that establishing an identity between inheritance and subtyping relations is paradoxical. Correct? > In commerical applications, almost ALL data is relational, > and so cannot be abstracted. The OO paradigm is not just > useless here, but downright destructive. Slow... What? I don't follow you here. > 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. I can't say. All the literature I read on OO languages (_Teach_yourself_C++_in_21_days_/_Java_for_Dummies_ :-) ) seems to indicate that RTTI is "intracardiac adrenaline" of fibrillating software systems. You try RTTI, then, if it dies all the same, you type "rpm --install ocaml-3.04.<your_arch>.rpm" and start a new life. > 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. That's why Linux is coded in C as opposed to C++. I wonder about the possibility of writing a functional kernel... Anyway, it is now appropriate to conclude with: Long live the Caml! Alex ------------------- 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