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!news.osn.de!diablo2.news.osn.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="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> <4176d6eb-fefe-4bd7-9378-55a33a12d458@e37g2000yqn.googlegroups.com> <5908c8c1-9a81-4877-a4da-827521b01263@p24g2000yqm.googlegroups.com> <1p8z3tc1d5rw6.jryi563tb4j5.dlg@40tude.net> <75592fbb-f9e8-4e4e-ae23-e63979f8925a@q4g2000yqm.googlegroups.com> <14ipqwq487sr.1gczeyh5apq5a$.dlg@40tude.net> <4b5444ab$0$7615$9b4e6d93@newsspool1.arcor-online.net> <1l74z2ijrog3d$.1af6vpgc2qq8c$.dlg@40tude.net> <4b547c92$0$6565$9b4e6d93@newsspool4.arcor-online.net> Date: Mon, 18 Jan 2010 17:41:41 +0100 Message-ID: NNTP-Posting-Date: 18 Jan 2010 17:41:41 CET NNTP-Posting-Host: dc017b59.newsspool3.arcor-online.net X-Trace: DXC=]`iifmni9A@0YVY]kmLTlDMcF=Q^Z^V3H4Fo<]lROoRA8kFOhAAB?G3FSgE X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8787 Date: 2010-01-18T17:41:41+01:00 List-Id: On Mon, 18 Jan 2010 16:21:53 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: >> On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote: >> >>> (3) adding subs to T to accomodate specified processing needs >>> of another, later program? How? >> >> By conversion of the object to another type: >> >> X : Integer; >> Y : Float := Float (X); -- Now we have sin, cos etc > > This conversion of a (then) persistent Integer object > to a Float object is possible because either type is known > (and can be named). You cannot have object of an unknown type. > The meaning of conversion from Integer > to Float is language defined, too. Type-defined. Conversion of concrete types is a doubly-dispatching primitive operation. Ada 83 didn't have dispatching operations and MD is still > What a persistent O-O storage would have to offer is something > in addition. > > In Toulouse: > > X : Private_Type_A; > begin > OO_Store.Put(X); > end; Put (OO_Store, "Some name", X); I prefer this notation, because this operation also is doubly-dispatching. > Then, where Identity is an identifier, or the object, or > a handle, or a filename, or ...: > > Pass(Identity(X), From => Toulouse, To => Hamburg); Rather: Put (OO_Store, Locate ("Hamburg") & "Some name", X); you do not need to pass anything. Store it where it belongs to. The main idea is that imperative I/O is normally not needed. "Pass" is disguised I/O. > In Hamburg: > > Y : Private_Type_B; > begin > OO_Store.Get(Y [, ]); > > How is Hamburg enabled to learn what Toulouse.Private_Type_A > is with the persistence layer functioning as the only source of > information about the object? In this case from some information outside: Y : Interested_In'Class := Get (OO_Store, "Some name"); > Which operations does it support? Of the class. When you create Y in your program you know what you are going to do with it. That is described by Interested_In. This is no different from knowing its name "Some name". This is a-priori knowledge. For example, a compiler expects an Ada source file. > What kind of conversions are possible, what granularity of > access to the object's innards might be needed to reify > the interface of Hamburg.Private_Type_B? There is a common ancestor for both types. What you probably had in mind was a conversion is between types from independent hierarchies rooted on different hosts. That normally should not be needed. To me the problem rather is in passing the concrete type of Y, which the program will never have to learn, but the run-time must. It will modify the dispatching tables, take the implementations of overridden operations in the form of some byte code (?) etc. >> IMO the real challenge (apart from consistent >> implementations of MI and MD) are dynamic types marshaled between the parts >> of a distributed system. I didn't think much about that, so don't expect me >> to answer how that should be solved. Probably others might have some >> insights... > > I guess this challenge is what some here had hoped to learn > about. You sounded like you knew the solution :-) I am sorry, then. There are hundreds of well paid people sitting in universities studying and teaching OS'es and distributed systems. Why are you asking me? Ask Andy Tannenbaum! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de