From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-10 18:39:56 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: 10 Sep 2003 18:39:54 -0700 Organization: http://groups.google.com/ Message-ID: References: NNTP-Posting-Host: 213.33.245.111 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1063244396 11922 127.0.0.1 (11 Sep 2003 01:39:56 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 11 Sep 2003 01:39:56 GMT Xref: archiver1.google.com comp.lang.ada:42363 Date: 2003-09-11T01:39:56+00:00 List-Id: olehjalmar kristensen wrote: > AK> Combining different roles in the same object may be a good thing > AK> as far as those roles do not interfere with each other. > AK> But in reality they may interfere by subtle and unforeseen way, > AK> in some singular points of the problem space. Therefore it is > > Of course, that's why I said you needed some care. However, in > practice, there will be little or no overlap, and thus little chance of > interference, precisely because you have modeled the different roles > properly. Also, you will typically use multiple virtual inheritance > via one common base class to allow the different roles to interact. > I'm talking about multiple inheritance as a tool for combining > carefully modeled, largely orthogonal roles in a single object, not as > a tool for grabbing whatever functionality happens to be in some class. Well, perhaps you are careful enough with these things, and aren't subjected to temptation "to grab whatever functionality happens to be in some class". But most programmers and software engineers surely have insuffiencet resistance to that temptation, and succumbed to it more or less often (as experience with *real* C++ programs shows quite clearly). So, it is important to differentiate both the need for and dangers of combining roles this way between the primarily modelling/simulation class of applications and the class of applications that are in close contact with real world (that is, with real objects and in real time). What you wanted is *symmetrical* combining roles. That symmetry indeed often happen in abstract models and may be very useful feature (and even a fundamental feature of the model); therefore it will be good to express this symmetry clearly and directly in source code. At the same time the risks associated with an unforeseen interference between the roles is relatively low, because the results of computation usually aren't applied immediately, but will be analyzed and interpreted by trained people in usually calm environment. But for the applications that are in close contact with real world, the situation is opposite. First, symmetry simply *never* exists in real world. Quite strong statement, isn't? A symmetry may appear as a satisfactory approximation in some conditions, which may emerge and disappear occasionally. Nobody can guarantee any symmetry for a particular small event in real world. Even a strong probablistic estimate for such a symmetry seems to be very rare possibility. Furthemore, even if we are able to prove that the conditions for symmetry (of roles) will be present then the next question is: how stable are our assumptions? Will they be still in place, say, 5 years ahead? (If you disagree with all that just said then please provide a counterexample - a pair of symmetrical real-world roles.) Now let's observe the risks associated with a conflict bewteen those "pseudo-symmetrical" roles. I think it is obvious enough that the risks are generally much higher here, just because our applications can cause immediate effects in the real world. So, a feature for (symmetrical) combining roles in Simula-67 was fully justified, while for Ada it seems undesirable. > Sure, you can always use delegation, and obtain precisely the same > interface to the object as if you had used multiple inheritance. But > then you are really just implementing it yourself. I can do that in C > too. No need for inheritance at all, really. I actually did this in a > project in the early eighties as we only had C, not Simula or some > other object oriented language available on our Unix system. Well, but basic delegation (and you need not more, if you want multiple inheritance, but do not expect from a compiler any complex specifics) may be implemented using canonical way; so you may develop a custom preprocessing tool (perhaps, using ASIS, if you wish a full-scale tool). and have Ada-MI (with file extension .ami -:) ... those who are unable to create such a tool for themselves surely do not deserve multiple iheritance in Ada -:) . You may also put this tool in public domain, and if it becomes highly popular then it may eventually convince ARG to reconsider their view on the subject... not for Ada200Y, but perhaps for Ada201Z -:) . Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia