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!news3.google.com!proxad.net!feeder1-2.proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!bnewspeer01.bru.ops.eu.uu.net!bnewspeer00.bru.ops.eu.uu.net!emea.uu.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 18 Jan 2010 12:23:23 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
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: 
 <da0b481d-9380-457a-94cf-c28c465ce78c@k19g2000yqc.googlegroups.com>
  <sg7o147u4q26.1y1lzuwi5ofjs$.dlg@40tude.net>
 <8e9bc311-7540-40a1-b19e-49e93648c25c@s31g2000yqs.googlegroups.com>
 <9oyblld05omh$.1dzhmyoseeb7x$.dlg@40tude.net>
 <414945fd-8ed5-4f42-a237-0685602332b3@f5g2000yqh.googlegroups.com>
 <nlnkgbioxwzd$.1j7fr3iwvxz8a.dlg@40tude.net>
 <4176d6eb-fefe-4bd7-9378-55a33a12d458@e37g2000yqn.googlegroups.com>
 <e3sbq7vcg1i$.1hwso5cuty27k.dlg@40tude.net>
 <d406a832-5ca4-489d-b5a0-adbd91e11303@v25g2000yqk.googlegroups.com>
 <xdym7qf5mr9a$.1ifcf3gdjnjlq$.dlg@40tude.net>
 <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>
In-Reply-To: <14ipqwq487sr.1gczeyh5apq5a$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4b5444ab$0$7615$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 18 Jan 2010 12:23:23 CET
NNTP-Posting-Host: 379a48f3.newsspool1.arcor-online.net
X-Trace: 
 DXC=DjC7G`K1ZFlf1oJaJ0@dmgic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbnDOROYlK6_`nc\616M64>jLh>_cHTX3jmbIW642GKU;`
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:8783
Date: 2010-01-18T12:23:23+01:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov schrieb:
> On Sat, 16 Jan 2010 13:18:46 -0800 (PST), Maciej Sobczak wrote:
> 
>> On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>
>>>> The blob becomes useful only when it is loaded into memory.
>>> How does it?
>> By becoming a typed entity that is referenced within the actively
>> executed program. This is the moment when blob becomes useful.
> 
> So the file containing a movie is useless?
> 
>> Several posts ago you have requested to execute actions on objects.
>> "Play" was an action on the movie - you wanted that. When I said that
>> the blob (a file, essentially) becomes useful when it is loaded into
>> memory, I meant that it is the interpretation of the blob that gives
>> it some requested capabilities.
> 
> Is there any player that loads movies into the memory?

This topic is rather interesting considering languages' I/O
sections. So its dicussion will profit from keeping it
technical. (The obvious idea here is that naggy remarks about
some presumed meaning of "load" could be more lucid.)
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,

(1) calling primitive subs defined with the object's type T

(2) learning about T's subs in case the object was stored
    by some program (defining T) not known to the caller,

(3) adding subs to T to accomodate specified processing needs
    of another, later program? How?