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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,dea2d62ab1462538 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!rz.uni-karlsruhe.de!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Writing an Operating System in Ada Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <8e9bc311-7540-40a1-b19e-49e93648c25c@s31g2000yqs.googlegroups.com> <9oyblld05omh$.1dzhmyoseeb7x$.dlg@40tude.net> <414945fd-8ed5-4f42-a237-0685602332b3@f5g2000yqh.googlegroups.com> <1c1x49re1atv3$.kxickttntzsn$.dlg@40tude.net> <26325363-b456-4c8f-a51d-4e87ef789619@a15g2000yqm.googlegroups.com> <754366b4-08c9-400b-b883-183e71dddd0b@35g2000yqa.googlegroups.com> Date: Thu, 14 Jan 2010 22:50:26 +0100 Message-ID: <1fhgwtz4ezt52.zvep41elk4lq.dlg@40tude.net> NNTP-Posting-Date: 14 Jan 2010 22:50:22 CET NNTP-Posting-Host: ef725cff.newsspool1.arcor-online.net X-Trace: DXC=;;6iDS<6ZQ_<<0iRN7DLEQic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgRdSh9VMa?D0X[6LHn;2LCV^[g\NTT9Kb\DEWV X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8760 Date: 2010-01-14T22:50:22+01:00 List-Id: On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote: >>>>> Why do you say that? >> >>>> Because there should be a honest MI and no interfaces. >> >>> But Ada doesn't support honest MI. How do you propose to work-around/ >>> implement that? >> >> By changing the language standard, of course. (:-)) > > Ah, but this brings up a question: HOW do we change it? 1. AI is sent to ARG. 2. ARG accepts AI. 3. ISO receives an amendment. 4. Springer Verlag prints the text... Or are you asking me how to implement MI? (:-)) >>> Furthermore, what sort of system would you use to >>> solve the diamond problem? >> >> I don't need to solve it. It is firstly not a problem and secondly it >> perfectly exists in interfaces: >> >> � �type A is interface; >> � �procedure F (X : A) is abstract; >> � �type B is interface and A; >> � �type C is interface and A; >> � �type D is interface and B and C; >> >> It also does in packages (with/use) and many other cases. > > But isn't B.F exactly equal to C.F in that we're using an inherited > procedure/function? Nope. A is an abstract list node, F is the operation get next node in the list. B is the list of devices. C is the list processes. Each note participates in two lists. > The diamond problem is about components named the > same that have different types... because interfaces ARE abstract > objects (with the further restriction that they are denied fields) > they don't suffer from the diamond problem. {That is the footprint of > Procedure Foo is EXACTLY the same in all three, they are all the > same.} Wrong: 1. There is no whatsoever difference between operations and fields. Each field is equivalent to a pair of primitive operations (getter and setter). 2. Whether an inheritance is additive or else idempotent depends on the problem space. It is not the language designer's choice. It is a common mistake to think otherwise. All misconceptions about MI stem from there. >>>> You do not need explicitly named contracts in a language like Ada. The >>>> contract of a type is the type itself. >> >>> Agreed, you could define all the operations of both inherited types, >>> have them as mix-in components, and handle things that way. That >>> method however excludes the option of saying something like "if Hybrid >>> in Clothing.Button" and "if hybrid in UI.Button" at the same time (you >>> could inherit from one and then be able to use one of the above, >>> true). >> >> Use T'Class with membership test S in T'Class. > > You're right I forgot the 'Class. But the problem still stands with it > rewritten as such. There is no problem, it is up to the programmer to decide about 2. If he chooses button interface to be additive, as in your case, the compiler shall support his choice. This is pretty simple to do because in Ada these conflicts are statically checkable. Resolving such conflicts is also no big deal. For example, one can rename operations upon inheritance hiding the conflicting ones. >> If you have a large system, you never know in advance. The code like above >> is from a real project. We are probably in a minority who actively deploy >> Ada 2005 features. We have a lot of interfaces and more we have them, less >> we enjoy them. He have approximately 20-30% of utterly meaningless cut and >> pasted code because of lack of MI. As a trivial example consider: >> >> � �type Read_File is limited interface; >> � �procedure Read (File : in out Read_File; ...) is abstract; >> >> � �type Write_File is limited interface; >> � �procedure Write (File : in out Write_File; ...) is abstract; >> >> � �type Read_Write_File is limited interface and Read_File and Write_File; > > I think it points to a bad design. IMO, I think something like this > would be in order: > > Type Abstract_File is limited interface; > -- All abstractable file operations go here. > Function Readable( File : in Abstract_File ) return Boolean is > Abstract; > Function Writable( File : in Abstract_File ) return Boolean is > Abstract; > Procedure Read ( File : in Abstract_File; Stream : > Stream_Class'Class ) is Abstract; > Procedure Write( File : in Abstract_File; Stream : > Stream_Class'Class ) is Abstract; > -- And so forth. 1. Since when God-classes became good design? 2. Your design defeats the very advantages of Ada as a statically typed language. I want Write to be *statically* checked. Otherwise I would use a dynamically typed language there are plenty of. >> How consider how would you implement these somewhere at the bottom of a >> hierarchy of concrete file types. Add there some other inheritance axis >> like handles to files, different contents, different devices (here you will >> badly need MD, but that is another story). Then observe how code >> duplication propagates from the bottom up all the inheritance levels >> multiplying itself at each. This is customary fought using generics which >> crown the mess. >> >>>> Sure. Translated to OO: FS is a specialized persistent container library. >> >>> Excellent. Why then would it be a bad idea to support FS-in-the- >>> abstract considering that currently [virtually] everyone's data is in >>> one instance or another of this "specialized persistent container >>> library"? >> >> Surely it is. > > That doesn't answer the WHY question. I don't propose to have no containers. >>> It would make things easier from the migration-to >>> standpoint. >> >> It would not, because the difference is not in a tree-like structure of >> named elements, but in the types of those elements. > > Um, are you forgetting the librarian/library/book metaphor from > earlier? The FILE is like the book, it's type is a property of the > abstract-type "book," the Library is the physical drive where you go > to get said book, the librarian is the one who knows how to traverse > the organization/disorganization within the library is the FS. (Not > all FSes are Hierarchical, think of them as some ADT holding some > File'Class objects.) I don't understand how this is related to the question how to handle books. >>>>>>>> Without MI, MD, tagged tasks, there is no chance to get >>>>>>>> it right. >> >>> Couldn't we emulate tagged tasks [to some degree] by having a "Tag" >>> entry with an output parameter giving the tag? >> >> You have to be able to derive from a task, that is what active objects are. >> BTW, you already can do this in Ada 2005. It has task interfaces, but this >> inheritance is limited to have the depth of 1. > > I remember reading that now... but is an inheritance level of 1 good > enough? No, it is not. The bottom level is an interface, a quite useless thing because it does not provide implementation. The next level is a concrete implementation. The train stops there. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de