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!a15g2000yqm.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Writing an Operating System in Ada Date: Thu, 14 Jan 2010 10:01:48 -0800 (PST) Organization: http://groups.google.com Message-ID: <26325363-b456-4c8f-a51d-4e87ef789619@a15g2000yqm.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> NNTP-Posting-Host: 75.161.14.239 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1263492108 28484 127.0.0.1 (14 Jan 2010 18:01:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 14 Jan 2010 18:01:48 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: a15g2000yqm.googlegroups.com; posting-host=75.161.14.239; 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:8750 Date: 2010-01-14T10:01:48-08:00 List-Id: > >> There shall be no interfaces at all. Ada 95 had everything needed, i.e= . > >> abstract types. Introducing interfaces in Ada 2005 was a huge mistake. > > > 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? Furthermore, what sort of system would you use to solve the diamond problem? Given two types, say a Clothing.Button and a UI.Button why shouldn't a clothing manufacturer be able to have a hybrid object implementing both contracts that would allow a customer to [for example] design the button they want on their clothing. (The specialized buttons for military dress-uniforms, say.) > 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). > Ada has type declarations, public and private. Everything visible related= to the type is the contract of. > Period. I agree that everything visible is the [ultimate] contract of the type. However I don't see why having an interface is any different than having as an inheritance-base a fully abstract object. Can you explain how you see it as such then? > 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 need = 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); > > That is a mess and a maintenance disaster. That sounds like a bad idea, true. But isn't it also an exercise in misdesign to throw in "just in case we need it" haphazardly? > > I think we have a failure-to-communicate here. I agree that relational > > algebra [blindly] works on tuples w/o knowing about the contents... > > that is in a sort of abstract fashion. > > > > If we use metaphor/allegory for the data-system [hard-drive, FS, data] > > would you agree that it could be likened to the following? > > The hard-drive is like unto a library containing books. > > The books of that library are like unto the data/files. > > The FS is like unto the indexing system (alphabetically by title, > > alphabetically by author, dewy-decimal, etc) coupled with the > > methodology for storing the 'books' (are they in boxes, on shelves, in > > a pile, etc). > > > Can we both agree on this? > > 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"? It would make things easier from the migration-to standpoint. True we wold have to have a method of determining the type of some file in the absence of type-data storage, but we would have to have such in any communication with some system which didn't use types. (*cough* UNIX *cough*) > >>>> 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? This also brings to mind: it could be _very_ useful if libraries & programs were objects-in-the-abstract (like a task type perhaps). > >>> If MD is multiple dispatch then we're talking about something that > >>> simply explodes combinatorically-speaking: Say we have a multi- > >>> dispatch procedure with two dispatching parameters [Letter and > >>> Number], ok? Now, if we have two versions of each of those in the > >>> classes we get something like: > >>> (A,1) > >>> (A,2) > >>> (B,1) > >>> (B,2) > > >> Yes. Let you have printer devices and shapes. This is a classical exam= ple > >> of MD. Yes, it explodes. That is the law of nature. There is nothing t= o do > >> about it, with MD support or without it, you have these combinations, = you > >> have to handle them. MD does not solve this, it merely provides an > >> infrastructure helping you to solve this. No more, no less. > > > Ah, I think I was confusing the problem with that infrastructure > > then... > > > But that does remind me, I was thinking it would be good to have > > PostScript as the display for the OS, unifying the visual display that > > way it would eliminate the need for printer drivers (assuming they're > > postscript printers) as well as providing a true WYSIWYG for print- > > preview (MS's print preview can be a bit... inaccurate), right? > > Right, but in an OO system you would barely need PostScript. I doubt > anybody would like to program in PostScript, so what is left? Poor as a > data carrier, unusable for humans. Doesn't it remind something? XML? (:-)= ) Exactly. For visual data to the screen and printer it would make a good unified format. We don't have to actually have people programming in PostScript, just have [UI] objects know how to output it and [display] objects know how to render it... which is EXACTLY the class a PostScript printer falls into.