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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!kanaga.switch.ch!switch.ch!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 18 Jan 2010 16:21:53 +0100 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Writing an Operating System in Ada 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> In-Reply-To: <1l74z2ijrog3d$.1af6vpgc2qq8c$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4b547c92$0$6565$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 18 Jan 2010 16:21:54 CET NNTP-Posting-Host: 49cc3e48.newsspool4.arcor-online.net X-Trace: DXC=NdI;@Y[f^aR@@RW1FjIB5S4IUKZLh>_cHTX3j]ZGMLD2LS9;U X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8786 Date: 2010-01-18T16:21:54+01:00 List-Id: Dmitry A. Kazakov schrieb: > On Mon, 18 Jan 2010 12:23:23 +0100, Georg Bauhaus wrote: > >> If there is a misunderstanding, please help: >> in a world of existing separate OSs, or of to be >> designed OSs, would their respective persistence layers allow, >> given the identifier of some object, > > Identifier of some object = the object itself, like when you write in Ada: > > X : Integer; > > X is the object and an identifier of. > >> (1) calling primitive subs defined with the object's type T > > Certainly. > >> (2) learning about T's subs in case the object was stored >> by some program (defining T) not known to the caller, > > No, you don't have the object then (object = identity + type + value). > First you have to convert the type of the object and get a view or else > another transient object of the desired type. Ada's equivalent: > > X : T'Class; > begin > ... S (X) ... -- S is a member of T'Class > > You might also be able to check if X in S'Class etc. > >> (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). The meaning of conversion from Integer to Float is language defined, too. That is, either object's type is known in the program storing X as an Integer and in the program processing X as a Float, respectively. In particular, the second program "knows" about the possibility of conversion of known type Integer to known type Float. 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; Then, where Identity is an identifier, or the object, or a handle, or a filename, or ...: Pass(Identity(X), From => Toulouse, To => Hamburg); 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? Which operations does it support? 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? I see a hole there that needs to be filled. Indeed: > 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 :-)