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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id A4409BB84 for ; Fri, 16 Jan 2009 16:18:51 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukQAHE0cElDWxLCYGdsb2JhbACBbJINHiqtTIYlhiWFcg X-IronPort-AV: E=Sophos;i="4.37,277,1231110000"; d="scan'208";a="19716187" Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194]) by mail2-smtp-roc.national.inria.fr with ESMTP; 16 Jan 2009 16:18:50 +0100 Received: from pc54.bertec.net (pc54.bertec.net [192.168.2.54]) by server1.bertec.net (Postfix) with ESMTP id A674D1056C4 for ; Fri, 16 Jan 2009 10:18:50 -0500 (EST) Message-Id: From: Kuba Ober To: caml-list@yquem.inria.fr Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: C++/C# inheritance is bad? Date: Fri, 16 Jan 2009 10:18:50 -0500 X-Mailer: Apple Mail (2.930.3) X-Spam: no; 0.01; yaron:01 minsky:01 foo:01 foo:01 compiler:01 wikipedia:01 amusing:01 cheers:01 disturbing:98 cult:98 cult:98 ellipse:98 ellipse:98 maintainable:98 regretted:98 Yaron Minsky wrote a while ago that "When we =EF=AC=81rst tried = switching =20 over from VB to C#, one of the most disturbing features of the language to the partners =20 who read the code was inheritance. They found it di=EF=AC=83cult to =EF=AC=81gure out = which =20 implementation of a given method was being invoked from a given call point, and =20 therefore di=EF=AC=83cult to reason about the code.". 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 =20= within the inheritance tree. So if something is a Foo, then it must not =20 matter that it's an instance that derives 5 levels deep from Foo. If the code is =20 written such that a derived class breaks the contract, the code is written =20 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. Most importantly, inheritance has never meant to be a way to reduce the amount of code. It's an incidental benefit, often cited as somehow the =20= raison d'etre of OO. If code reuse stands in the way of upholding the interface contract, the contract wins in spite of code duplication. The best =20 example, perhaps, is the *widely abused* circle/ellipse inheritance. The fact =20 that, mathematically, a circle is an ellipse, does *not* mean that in OO =20 language you should derive a circle class from an ellipse class -- it makes no =20= sense at all if you think about it from the standpoint of interface =20 contracts. In OO world, a circle is *not* an ellipse. An ellipse has two radii, a =20 circle doesn't, that's where the story ends. The Wikipedia article about that problem is amusing in the numerous examples they show that could supposedly "fix" it somehow. I have not seen any decent, maintainable C++ code =20 where the Liskov's substitution principle was violated. I have violated it =20 myself in my early years of learning C++, and I have only regretted it. So, when correctly applied, what's so disturbing about inheritance? =20 You inherit only where it makes sense, and if it makes sense then you don't care =20 about which particular method is called: it's supposed to be safe. Cheers, Kuba=