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 XAA08620; Thu, 7 Aug 2003 23:53:32 +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 XAA01274 for ; Thu, 7 Aug 2003 23:53:30 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h77LrSf01502 for ; Thu, 7 Aug 2003 23:53:29 +0200 (MET DST) Received: from ozemail.com.au (203-213-127-88-syd-ts20-2600.tpgi.com.au [203.213.127.88]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h77LrOo03235; Fri, 8 Aug 2003 07:53:24 +1000 Message-ID: <3F32CA53.4090505@ozemail.com.au> Date: Fri, 08 Aug 2003 07:53:23 +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: caml-list@inria.fr CC: ocaml_beginners@yahoogroups.com Subject: Re: [Caml-list] static class member.... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; ozemail:01 caml-list:01 woodyatt:01 stupid:01 abstracted:01 abstraction:01 ocamldoc:01 sensibly:01 non-trivial:01 encapsulate:01 abstractions:01 toxteth:01 glebe:01 2037,:01 9660:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk james woodyatt wrote: > I would strongly second this advice. When I came to Ocaml from C++, I > did not heed this advice-- and I wasted a lot of time learning why that > was a mistake. Actaully, my advice to C++ programmers is the same :-) Don't use classes. Plain old data structures are generally better -- precisely because they *don't* provide encapsulation. This saves a whole lot of time writing methods, when you could just manipulate the data structure directly. Just kill off stupid Visitor patterns and things and write the code you need without encumbering yourself with attempts to abstract things that usually aren't abstract in the first place. In most business code, even the kinds which are in principle abstractable are often best not abstracted simply because there aren't enough instances of the abstraction to bother, and the client is sure to change the rules and break your polymorphism anyhow :-) An example where abstraction is useful: the back end of a code generator (such as Ocaml itself, or Ocamldoc), can sensibly be abstracted. However getting the abstraction just right is a non-trivial exercise and it's often better to do case by case encoding until the actual abstraction emerges in the code itself (and then you can encapsulate it). To put this another way -- don't use abstractions unless you have a strong theory that tells you what they actually are, and even then, be circumspect ... -- 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