TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
AdaWorks <[log in to unmask]>
Date:
Sat, 20 Feb 1999 14:23:41 -0800
Reply-To:
"Robert C. Leif, Ph.D." <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Subject:
From:
"Robert C. Leif, Ph.D." <[log in to unmask]>
X-cc:
[log in to unmask], Howard Stewart <[log in to unmask]>, PaulWhittington <[log in to unmask]>
In-Reply-To:
<Pine.3.89.9902200435.A2882-0100000@netcom17>
Content-Type:
text/plain; charset="iso-8859-1"
MIME-Version:
1.0
Parts/Attachments:
text/plain (75 lines)
From: Bob Leif
To: Richard Riehle et al.

You are correct. However, one great advantage of providing the Ada source
text is that it can be recompiled on different processors. The problem then
becomes how does one transmit the data between different computers.
Standards such as DICOM (Digital Imaging and Communications in Medicine)
have, at least, attempted to address this issue. One very obvious point. The
choice of endian employed for transmission should be totally decoupled from
that used for storage.

I had suggested to INEEL that they collaborate with Michael Card of
Lockheed-Martin in Syracuse. I believe that Card has included standard
relational database operations for "atomic types" in his object database.
Conversely, many of the attributes of the "objects" in object databases are
suitable for manipulation with relational technology.

It would be of significant interest to determine how much of the existing
AdaSAGE databases could be ported to Card's FIRM: An Ada Binding to ODMG-93
1.2. or an extension thereof.

Parenthetically, if any of the readers of Team-Ada have problems with the
original PostScript versions of FIRM Adobe Acrobat Distiller translated the
June 25, 1997 PostScript version into PDF format. The file size shrank from
1,620 KB to 445 KB.

> -----Original Message-----
> From: Team Ada: Ada Advocacy Issues (83 & 95)
> [mailto:[log in to unmask]]On Behalf Of AdaWorks
> Sent: Saturday, February 20, 1999 4:43 AM
> To: [log in to unmask]
> Subject: Re: persistent object in Ada
>
>
> In the object database domain, persistence is the quality of an object to
> retain its ability for polymorphic behavior even while store in some
> secondary device.  This means the object always knows how to dispatch
> when read into a program's primary memory.
>
> In Ada 95 this capability is reflected in Stream_IO's ability to preserve
> the tag of the object when storing it into a file.  Upon reading such an
> object, any dispatching operation can be invoked because of the
> persistence
> of the tag.  In this sense, it is not the only data which is
> persistent (of
> course it is) but also the operations on the data.
>
> This is fundamental challenge of object database software:  how do we make
> both the data and the operations on the data persistent?
>
> Although the Ada "tag" is useful for this purpose in some environments,
> it is not portable across all compilers. Each compiler has its own model
> for a tag.  Therefore, the tag, while a useful feature for designing an
> object database that will always be processed by the same compiler on
> the same machine, does not satisfy the larger problem of persistence as
> understood in the world of object database design.
>
> For a good paper on this subject in the context of Ada 95, see the work of
> Michael Card of Lockheed-Martin in Syracuse. I think it is
> available on one
> of the Ada web sites.
>
> Richard Riehle
>
> Richard Riehle
> [log in to unmask]
> AdaWorks Software Engineering
> Suite 30
> 2555 Park Boulevard
> Palo Alto, CA 94306
> (650) 328-1815
> FAX  328-1112
> http://www.adaworks.com
>

ATOM RSS1 RSS2