From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 49995BB84 for ; Sat, 17 Jan 2009 15:35:25 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIDACh7cUlDWxLCbmdsb2JhbACBa5IYPqpEhimGVoVz X-IronPort-AV: E=Sophos;i="4.37,280,1231110000"; d="scan'208";a="22630441" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Jan 2009 15:35:24 +0100 Received: from [IPv6:::1] (server2.bertec.net [192.168.2.6]) by server1.bertec.net (Postfix) with ESMTP id 762B11056C4 for ; Sat, 17 Jan 2009 09:35:23 -0500 (EST) Message-Id: From: Kuba Ober To: caml-list@yquem.inria.fr In-Reply-To: <200901171327.19141.jon@ffconsultancy.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Caml-list] C++/C# inheritance is bad? Date: Sat, 17 Jan 2009 09:35:22 -0500 References: <200901171327.19141.jon@ffconsultancy.com> X-Mailer: Apple Mail (2.930.3) X-Spam: no; 0.00; workarounds:01 multimethods:01 implements:01 model:01 ocaml:01 cheers:01 2009:98 disturbing:98 disturbing:98 sealed:98 wrote:01 wrote:01 abstract:01 caml-list:01 inherit:01 On Jan 17, 2009, at 8:27 AM, Jon Harrop wrote: > On Friday 16 January 2009 15:18:50 Kuba Ober wrote: >> So, when correctly applied, what's so disturbing about inheritance? > > Inheritance is disturbing because, in general, it cannot be applied > correctly. > That is why there are so many workarounds, many of which do not even > exist in > C++ like final methods, sealed classes, multimethods, extractors and > so on. > OO is not good in all circumstances and other tools can be > preferable. IME, > OO is only very rarely the best solution and it is only chosen so > often > because it is typically the only solution available (e.g. in C++ or > Java). > >> You inherit only where it makes sense, and if it makes sense then >> you don't >> care about which particular method is called: it's supposed to be >> safe. > > Safety is quite different from easy of use, of course. I know I'm perhaps overusing Qt as an example, but it's just handy. In Qt, the basic "instrumented" class is QObject. It implements retrospection, signal/slot mechanism, etc. QWidget (a GUI building block) derives from it. (and from a QPaintDevice, since you can paint on it). Then, you have various widgets that derive from QWidget. Some of those are abstract widgets (interfaces), like QAbstractButton, where a concrete class faces the end user, like QPushButton. It is quite a straightforward model -- as long as you think of it in terms of "ISA" relationship between classes. I wonder how such a hierarchy would be implemented in a natural way in OCaml? By "natural" I mean being good practice and not feeling like a hack. One should remember that users must extend the framework, so it should be easy to extend say QWidget to create your own "class". Cheers, Kuba