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-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!188.40.43.213.MISMATCH!feeder.eternal-september.org!eternal-september.org!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool3.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="us-ascii" Content-Transfer-Encoding: 7bit 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> Date: Thu, 14 Jan 2010 09:55:41 +0100 Message-ID: <1c1x49re1atv3$.kxickttntzsn$.dlg@40tude.net> NNTP-Posting-Date: 14 Jan 2010 09:55:41 CET NNTP-Posting-Host: 3c292e09.newsspool3.arcor-online.net X-Trace: DXC=KFj]f;9^XnO2jYf>V4L0gLMcF=Q^Z^V3H4Fo<]lROoRA8kFO`=`MXoZT8?F X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8739 Date: 2010-01-14T09:55:41+01:00 List-Id: On Wed, 13 Jan 2010 14:50:50 -0800 (PST), Shark8 wrote: >>> If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005 >>> interfaces handle that pretty well. >> >> 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. > I see them as just being a contract for functions/ > procedures that some object must provide, and in that sense there is > no reason why an actual object-class cannot agree to one or more of > these 'contracts'. One nice thing Delphi did was to allow an interface > to be implemented by a field of the class, they called this "interface > delegation" and looked something like this: > Type TExample = Class(TObject, IDelegated) > private > DelegationField : TSomeDelegatedObject; > public > property Delagator : TSomeDelegatedObject read DelegationField > write DelegationField implements IDelegated; > end; //Example You do not need explicitly named contracts in a language like Ada. The contract of a type is the type itself. Ada has type declarations, public and private. Everything visible related to the type is the contract of. Period. > I suppose you could call it 'subcontracting'. There should be plain interface inheritance instead. If you wanted the type S to implement the interface of the type T *without* inheriting the implementation of T, you should be able to tell just so. Rather than *in advance* trying to declare all possible interfaces. It is awful and leads to an explosion of meaningless declarations like: type T_Interface is interface ... ; -- Just in case we would need it! procedure Foo (X : T_Interface) is abstract; type T is new T_Interface with ...; -- No we starting to work overriding procedure Foo (X : T); That is a mess and a maintenance disaster. >>> If the drive is a dictionary, the entries are the particular files/ >>> directories/objects thereon, but it is pretty useless to give someone >>> a dictionary in a language they can't read. >> >> No, it only means that the object called dictionary is supported and other >> objects called articles are not. The same error was made by the relational >> data bases, they understand the structure of relations (relational >> algebra), but do not do the elements of the tuples. > > 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. >>>> Without MI, MD, tagged tasks, there is no chance to get >>>> it right. >> >> >>> 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 example >> of MD. Yes, it explodes. That is the law of nature. There is nothing to 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? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de