Path: utzoo!attcan!uunet!efi!tim From: tim@efi.com (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Multiple Inheritance -- Is It A Luxury? Message-ID: <1990Jul13.182940.1099@efi.com> Date: 13 Jul 90 18:29:40 GMT References: <15132@reed.UUCP> <268BA8DC.4CD4@intercon.com> <8937@goofy.Apple.COM> <268C032E.5137@intercon.com> <1990Jul2.181147.1672@efi.com> <9007@goofy.Apple.COM> Organization: Electronics For Imaging, Inc. Lines: 57 In article <1990Jul2.181147.1672@efi.com> tim@efi.com (Tim Maroney) writes: >>The people doing the MPW compilers seem to think that multiple >>inheritance is not important. It's not possible at all in Object >>Pascal, and apparently is impossible to use in real (handle-based) >>applications in C++. I think this is a cavalier attitude. I've only >>been using Object Pascal for a couple of months now, and my only >>earlier OOP experience was with a flavored dialect of Franz Lisp many >>years ago; but I have already encountered a number of cases where the >>lack of multiple inheritance imposes inelegant solutions. The >>"seaplane" analogy seems to be a frivolous way of dismissing this >>important technique. In article <9007@goofy.Apple.COM> shebanow@Apple.COM (Andrew Shebanow) writes: >Although it might seem hard to believe given the inflammatory tone >of Tim's missive, there are many people here at Apple who think >that MI is important. What I find hard to believe is that anyone would seriously call the above "inflammatory". There seems to be an attitude that any criticism of Apple technical policy is inherently inflammatory, even if its language is moderate and its arguments carefully drawn. Is it really "inflammatory" to call an attitude "cavalier" and an argument "frivolous"? If so, how would it be possible to make any criticism that was not "inflammatory"? >The limitations on the use of MI in handle based objects are caused >by C++'s object model, and not by a lack of concern on the part >of Apple's engineers. If anyone can figure out a good way to solve >this problem without rewriting all of CFront, we would of course be >very interested in hearing about it. A number of small developers have come out with native C++ compilers for DOS, I believe. I doubt that writing a compiler would be a serious strain on Apple's bountiful development resources. cfront is a slow interim solution, which you'll have to break with sooner or later. However, I don't know that the best way to solve the problem involves handle+offset ways of accessing objects, as suggested by a few people here. Suppose that an object begins with a class offset table, consisting of an array of pairs (class id, offset to members). Then the generated code uses a double-offset operation to get to the members of the class it's dealing with. There is a small performance penalty, but it keeps the model fairly clean, and you only have to do the table lookup once per object per method. >Object Pascal doesn't support MI primarily for historical reasons. >The language wasn't designed with MI in mind, and adding MI >to it would be a decidedly non-trivial change. However, Apple's >Advanced Technology Group is looking at doing an updated >version of the Object Pascal language - for more information, >see the last issue of the MacApp Developer's Association publication, >Frameworks". Perhaps we should subscribe to it. Object Pascal has two major deficiencies. One is the lack of multiple inheritance; the other is the lack of information hiding (private methods and members). Is the ATG also looking at adding information hiding?