From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA06794; Fri, 19 Jul 2002 20:15:49 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA06785 for ; Fri, 19 Jul 2002 20:15:44 +0200 (MET DST) Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g6JIFfv26080 for ; Fri, 19 Jul 2002 20:15:42 +0200 (MET DST) Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g6JIFYSs029710; Sat, 20 Jul 2002 04:15:34 +1000 (EST) Received: from ozemail.com.au (ppp35.dyn1.pacific.net.au [61.8.1.35]) by wisma.pacific.net.au with ESMTP id EAA27873; Sat, 20 Jul 2002 04:15:30 +1000 (EST) Message-ID: <3D38573E.2030908@ozemail.com.au> Date: Sat, 20 Jul 2002 04:15:26 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Alessandro Baretta CC: Andreas Rossberg , ocaml Subject: Re: [Caml-list] productivity improvement References: <20020716172916.4903.qmail@web10702.mail.yahoo.com> <200207190358.XAA11620@dewberry.cc.columbia.edu> <20020719010318.B3631@boson.den.co.bbnow.net> <200207190821.EAA09974@hickory.cc.columbia.edu> <3D37D474.2551F19E@ps.uni-sb.de> <3D37E669.6050608@baretta.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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