comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Address of an object
Date: Tue, 19 Sep 2006 15:29:00 +0200
Date: 2006-09-19T15:29:00+02:00	[thread overview]
Message-ID: <r2gn9ai43h1t$.zihrnwkgw6b7$.dlg@40tude.net> (raw)
In-Reply-To: u3bao9q0a.fsf@stephe-leake.org

On Tue, 19 Sep 2006 05:15:01 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> So you want access to some compiler-dependent information; clearly the
>>> method will be compiler-dependent, since it isn't defined by the language.
>>
>> No, I don't want to access it. I only want my information.
> 
> I don't understand. You want write-only data?

No, I just don't care about them. As an example consider a container
library or a garbage collector. They don't care about handling the data.

>>> What are you going to do with the "dopes" you add? They won't be
>>> visible from Ada.
>>
>> That's exactly the goal, because what I want is to extend types in a way
>> Ada does not support. I wanted to add something to a type without
>> quarreling with Ada, which mistakenly [OK, that was a political decision]
>> does not support MI. It was corrected in Ada 2005 but only for pure
>> interfaces, while I need implementations. There is a vast number of cases
>> where it might be useful.
> 
> So you are trying to extend the Ada language. You should be editing
> the compiler; that's one of the reasons GNAT is open source.

GNAT is, but Ada isn't. For extending Ada there are AIs. 

>> It seemed quite easy, thank to user-defined pools. Well, actually it is
>> spoiled a bit with pointers and generics, but that's another story. 
> 
> Actually, that's part of the reason MI isn't in Ada. You must consider
> how it impacts the entire language.

There cannot be any negative impact. Fundamentally, if MI is infeasible,
then single inheritance must be as well. Once Ada has decided to support
inheritance there is no return.

>> The idea is as follows:
>>
>> 1. You define a pool which eventually takes its memory from some another
>> pool.
>>
>> 2. When something is allocated in the pool, you just add necessary data to
>> the allocated object in front of the allocated memory block
>>
>> 3. The interface to this is a generic package, which provides a pointer
>> type to the objects in the pool. [Unfortunately, the type of the pointer's
>> pool cannot be made opaque, but that is a minor language problem.]
> 
> So this generic package needs to read the data, from Ada. Or at least
> provide a pointer to it, so other Ada packages can read it.

Sure. The pointer is a legal access type, you can do with it and through it
anything, one could do in Ada.

>> 4. New operations are defined on the pointer type.
> 
> In Ada, or some other language?

Of course in Ada. OK, I feel there is a need to give an example. I will
start a new thread for it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de



  reply	other threads:[~2006-09-19 13:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-15 20:24 Address of an object Dmitry A. Kazakov
2006-09-15 23:31 ` Adam Beneschan
2006-09-16  8:13   ` Dmitry A. Kazakov
2006-09-18 10:29     ` Stephen Leake
2006-09-18 12:09       ` Dmitry A. Kazakov
2006-09-18 13:54         ` Maciej Sobczak
2006-09-18 14:53           ` Dmitry A. Kazakov
2006-09-19  9:15         ` Stephen Leake
2006-09-19 13:29           ` Dmitry A. Kazakov [this message]
2006-09-16 13:21 ` Stephen Leake
2006-09-16 17:06   ` Dmitry A. Kazakov
2006-09-20  0:43     ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox