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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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!postnews.google.com!35g2000yqa.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Writing an Operating System in Ada Date: Thu, 14 Jan 2010 13:07:08 -0800 (PST) Organization: http://groups.google.com Message-ID: <754366b4-08c9-400b-b883-183e71dddd0b@35g2000yqa.googlegroups.com> 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> NNTP-Posting-Host: 71.222.209.74 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1263503228 19064 127.0.0.1 (14 Jan 2010 21:07:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 14 Jan 2010 21:07:08 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 35g2000yqa.googlegroups.com; posting-host=71.222.209.74; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 4.0.20506),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:8758 Date: 2010-01-14T13:07:08-08:00 List-Id: > >>> 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? > > 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: > > =A0 =A0type A is interface; > =A0 =A0procedure F (X : A) is abstract; > =A0 =A0type B is interface and A; > =A0 =A0type C is interface and A; > =A0 =A0type 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? 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.} > >> 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. > (It is a bit sloppy that Ada uses "in" both for S in T and for S in > T'Class. In mathematics membership and subset are two distinct relations) True. But if we're talking about an OO hierarchy then a derived-member of some class IS a superset of that class; and also as things fall into a nice hiearchy, we see that these classes themselves are sets. > Why do I need interface? What does it add to > > =A0 =A0type T is abstract private; > > existed in Ada 95. (Answer: it adds a new reserved word! (:-)) LOL > >> Rather than *in advance* trying to declare all possible interfaces. It= is > >> awful and leads to an explosion of meaningless declarations like: > > >> =A0 =A0type T_Interface is interface ... ; -- Just in case we would ne= ed it! > >> =A0 =A0procedure Foo (X : T_Interface) is abstract; > >> =A0 =A0type T is new T_Interface with ...; -- No we starting to work > >> =A0 =A0overriding procedure Foo (X : T); > > > If you have a large system, you never know in advance. The code like abov= e > 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, les= s > we enjoy them. He have approximately 20-30% of utterly meaningless cut an= d > pasted code because of lack of MI. As a trivial example consider: > > =A0 =A0type Read_File is limited interface; > =A0 =A0procedure Read (File : in out Read_File; ...) is abstract; > > =A0 =A0type Write_File is limited interface; > =A0 =A0procedure Write (File : in out Write_File; ...) is abstract; > > =A0 =A0type 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. > 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 wi= ll > 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 libra= ry. > > > 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. > > 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.) > >>>>>> 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 ar= e. > BTW, you already can do this in Ada 2005. It has task interfaces, but thi= s > inheritance is limited to have the depth of 1. I remember reading that now... but is an inheritance level of 1 good enough? Possibly if we were to abstract things in the correct manner. If the inheritance level is one, is it also legal to have task types Abstract_Program and Abstract_something which are both implemented in a single class/case? {It would have the requisite depth of 1...}