From -7900234587211229240 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,fdf5ec91b4c47347 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-02-06 10:25:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: o.v@k.ro (O.V.) Newsgroups: comp.std.c++ Subject: Re: Some features to be added to class-based OO languages Date: Thu, 6 Feb 2003 18:25:00 +0000 (UTC) Organization: http://groups.google.com/ Lines: 83 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <59143289.0302060856.275bad99@posting.google.com> References: <59143289.0301280527.1e95174d@posting.google.com> <7f2735a5.0302031617.31c35622@posting.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1044555900 11319 10.0.0.1 (6 Feb 2003 18:25:00 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 6 Feb 2003 18:25:00 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18gqhk-0002wP-00 for mail2news@news.news.demon.net; Thu, 06 Feb 2003 18:24:56 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA26066; Fri, 7 Feb 2003 05:24:51 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: 6 Feb 2003 16:56:12 GMT X-Spam-Status: No, hits=-9.7 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Xref: archiver1.google.com comp.std.c++:17840 allan_w@my-dejanews.com (Allan W) wrote in message news:<7f2735a5.0302031617.31c35622@posting.google.com>... > o.v@k.ro (O.V.) wrote > > > 1. Dynamic inheritance > > > > The major drawback of the classical inheritance scheme are the > > limitations in combining different types (classes) on the same object. > > Letting an object of class A be also of class B and C can be > > difficult, especially when B and C are subclasses of A. This is not > > easily accomplished even with multiple inheritance. > > Dynamic inheritance solves this by allowing the base object of a > > derived object to be chosen explicitly in the client function. > > > > Dynamic inheritance is provided in some languages, but it is said to > > be difficult or even impossible to support in class-based languages. > > It is also said to be unsafe, which may be true, but in my view the > > benefits are substantial enough to be worth having it. As for the > > implementation difficulties, I may be wrong but I really don't think > > so. I will therefore give a brief description of what I have in mind; > > it may be a somewhat limited version but provides in my opinion most > > of the benefits of the full scheme. And it's doable; in fact the > > interface-based approach can be implemented with some small effort in > > today's C++. > > Would you please reword this? Assume that most of your audience is > like me: almost all of my OO experience comes from C++, so any > proposal to change the OO foundation in C++ is going to seem as if > it was no longer OO, even if it really is more so. If you lived > your whole life in the African desert, and then someone showed you > an ice cube and said, "this is water," you would have trouble > seeing it -- that's probably similar to why I can't understand your > point here. I'm not going to reword this because I think it expresses exactly what it should. However, I confess I'm also like you, most of my OO experience comes from C++, and I really like your analogy with the ice cube. > In particular, I've spent many years modeling data to fit well > with the concept of C++'s classes. A Hyundai is-a car is-a vehicle > is-a machine, and so on. It seems like you want to allow some > functions to allow that a Hyundai is-a duck, even though that isn't > true anywhere else in the program. In my experience it would make > more sense to create a Hyundai_Duck class, either with multiple > inheritance or with a contained duck. Obviously what you have in > mind is something different; you want to (temporarily?) look at > Hyundai and (without changing the data?) consider it as a type > of duck. Is that close? No. Think of it like this: if I have a Hyundai class and a Duck class, I am able in a function to create an object that is a Hyundai and a Duck. So that the common virtual methods call each other well. In fact, I have to indicate more, in order that the methods call well: I have to say which one is on top, the Hyundai or the Duck. Exactly one of them must be on top, and a Hyundai on top of a Duck is usually something quite different than a Duck on top of a Hyundai. But both types are as well a Hyunday as they are a Duck, same way as a Hyundai is still a car, even if it has something on top of it (the Hyundai part). Anyway, this in no way implies that a Hyundai is a Duck. If I want to create classes for such objects, that is Hyundai's on top of Ducks or Ducks on top of Hyundai's, I can, the way I explained in my posting. This can be fairly well achieved with multiple inheritance or with containining classes, as long as there are no common virtual methods that must call each other well. If there are such methods, the best approach imo is dyn. inheritance. > I'd like to see some (hopefully simple) example of how this would > be used and why it would be an advantage. In my posting, I have given the best example I know. It may not be the simplest possible one, but it's definitely not complicated, and it's worth reading, I hope. Anyway, thanks also for your interest. O.V. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]