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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,fa22a73e140a6fd1
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.129.169 with SMTP id nx9mr8019947pbb.8.1326198461023;
        Tue, 10 Jan 2012 04:27:41 -0800 (PST)
Path: 
 lh20ni163549pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!news.osn.de!diablo2.news.osn.de!news.belwue.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 10 Jan 2012 13:27:38 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Object-Oriented style question
References: <4f098fcb$0$6577$9b4e6d93@newsspool3.arcor-online.net>
 <11047e9f-a7ef-4728-8e1c-4202c5958e9c@ck5g2000vbb.googlegroups.com>
 <4f0b7f2b$0$7617$9b4e6d93@newsspool1.arcor-online.net>
 <36ee3b54-496c-41d4-a8ba-3357741adada@p4g2000vbt.googlegroups.com>
In-Reply-To: 
 <36ee3b54-496c-41d4-a8ba-3357741adada@p4g2000vbt.googlegroups.com>
Message-ID: <4f0c2ebb$0$7626$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 10 Jan 2012 13:27:39 CET
NNTP-Posting-Host: ab7cd190.newsspool1.arcor-online.net
X-Trace: 
 DXC=X0GoDh=[MYjIkjb;<8iR=aic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbPhBQN`[]M5cnc\616M64>jLh>_cHTX3jmf^CWWRk`@=d
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2012-01-10T13:27:39+01:00
List-Id: <comp.lang.ada>

On 10.01.12 09:47, Maciej Sobczak wrote:

>> The effect is that there still wouldn't be any parameters of an
>> anonymous access-to-object type at the level of T's definition.
> 
> Why this should be a goal?

For two reasons.

First, just restating that, as already agreed, the definition of
O-O types T should normally be concerned with operations defined
for the type T more than with operations defined on access T,
adopting Dmitry's parlance, if I may, for the sake of the argument.

Second, a pointer as a key can be seen as an implementation detail
used as an abstraction. More on this below.

> I prefer if the profile describes what is going on. If sh*t is going
> on, then it is better to show it in the profile than to hide it and
> surprise the user later.

Absolutely.

I wonder, though, whether the convention (using pointers to hint
at lifetime and identity) could be turned into a different setup.
The resulting types may entail more work, but perhaps also more
flexibility. Suppose objects' lifetimes can be interrupted.
For example, objects that can be "serialized" to external storage.
They then seize to exist. Later, the program may load the objects
from external storage, bringing them to life again. Perhaps on
a different machine/node/partition. This might effectively mean
that addresses of objects have changed.

A client program wishes access to an object that it "thinks" must exist,
because it has worked on this object before, knowing its identity
(via its access value). If every such object has a unique ID, and
this ID is used in place of its 'Access, then requesting access
to the object may trigger loading the object from external storage,
using said unique ID. Is this possible with pointers?