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=0.8 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id F03D1BB84 for ; Fri, 16 Jan 2009 16:58:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksDANA9cElQRFuwgWdsb2JhbACUBAEBFiK5eoVyhEs X-IronPort-AV: E=Sophos;i="4.37,277,1231110000"; d="scan'208";a="19718537" Received: from furbychan.cocan.org ([80.68.91.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 16 Jan 2009 16:58:07 +0100 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1LNr5C-0002fO-Pc; Fri, 16 Jan 2009 15:58:06 +0000 Date: Fri, 16 Jan 2009 15:58:06 +0000 To: Kuba Ober Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] C++/C# inheritance is bad? Message-ID: <20090116155805.GA8664@annexia.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; ocaml:01 foo:01 foo:01 compiler:01 debugger:01 confuses:01 functors:01 extensively:01 camlp:01 elegantly:01 2009:98 wrote:01 caml-list:01 precisely:01 argument:02 On Fri, Jan 16, 2009 at 10:18:50AM -0500, Kuba Ober wrote: [...] OCaml? > I was always puzzled about such an argument. Scott Meyers points out > at every opportunity that in C++ (and, by extension, in OO languages > in general), the class's interface is a contract that has to be > upheld within the inheritance tree. So if something is a Foo, then > it must not matter that it's an instance that derives 5 levels deep > from Foo. If the code is written such that a derived class breaks > the contract, the code is written wrongly and will cause no end of > trouble. It's another story, of course, how to uphold such contracts > in your development environment: how much can the compiler do, how > much can the test harness do, how much is done via static code > analysis tools, etc. I guess that's precisely the point. It's when you're at the sharp end of a deadline and a debugger that you need to reason about the code. Inheritence confuses the matter greatly because the code can be spread over many files, and in fact it may not be possible to see the code that really gets executed. More dynamic IDEs can help here, but the basic problem will remain as long as people keep using inheritence. Functors suffer from the same problem by the way, particularly when used extensively as in the source code for camlp4. I have a more fundamental question: Is inheritence actually useful for anything? By which I mean, are there real world problems which are solved elegantly with inheritence which are otherwise difficult to solve? I'm not sure I've seen many. I have seen many very tortuous class hierarchies though. Rich. -- Richard Jones Red Hat