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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,447bd1cf7a88c198
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-01-05 11:24:06 PST
Path: 
 supernews.google.com!sn-xit-03!supernews.com!freenix!proxad.net!grolier!btnet-peer0!btnet!dispose.news.demon.net!demon!diablo.dera.gov.uk!dera!not-for-mail
From: "Kevin Rigotti" <rigotti@atc.dera.gov.uk>
Newsgroups: comp.lang.ada
Subject: Object naming conventions (was: Do we need "Mission-Critical"
 software?)
Date: Fri, 5 Jan 2001 19:20:39 -0000
Organization: Defence Evaluation & Research Agency
Message-ID: <9356q9$ig9$1@trog.dera.gov.uk>
References: <3A4F5A4A.9ABA2C4F@chicagonet.net> <3A4F759E.A7D63F3F@netwood.net>
 <3A50ABDF.3A8F6C0D@acm.org> <92qdnn$jfg$1@news.huji.ac.il>
 <3A50C371.8B7B871@home.com> <3A51EC04.91353CE7@uol.com.br>
 <3A529C97.2CA4777F@home.com> <3A53CB9E.EA7CF86C@uol.com.br>
 <3A5466DE.811D43A5@acm.org> <932aol$ikc$1@nnrp1.deja.com>
 <932mi6$r2k$1@trog.dera.gov.uk> <9343b1$3g5$1@nnrp1.deja.com>
 <934iuf$eqv$1@nnrp1.deja.com> <umq1yuixba0.fsf@maestro.clustra.com>
NNTP-Posting-Host: 194.61.191.135
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Xref: supernews.google.com comp.lang.ada:3695
Date: 2001-01-05T19:20:39+00:00
List-Id: <comp.lang.ada>

I really don't think that there is a problem at the source code level. I
would strongly agree with Robert Dewar that Ada provides far more support
for multi-language programming than any other language.

The first thing I wrote in Ada95 a few years back was to extend a version of
"rpcgen" to produce Ada stubs for a distributed simulation platform written
in C, and it was easier and cleaner with Ada95 than it would have been in
Ada83 or anything else.

Where things tend to get a bit mucky at the moment is the object code level.
Interfacing to C is easy because it only has one level at which to define
external symbols, so the names are predictable. Once you have nesting of
various kinds then the names become very compiler dependent, which makes it
a real pain in the neck to call out to C++ from Ada or vice versa, which is
what a lot of people would like to be able to do (getting back to the point
of my earlier posting).

GNAT is well behaved in its choice of names, for example a procedure Reset
in package Cactus.Random becomes "cactus__random__reset". Nothing surprising
there.

Compare that to "_R_reset.random.cactus.9dmo0dr4xkkbonjxay" for the same
thing compiled with Rational Apex and its no surprise that interoperability
can sometimes be a problem.

Rather than constructing elaborate wish lists for "Ada0X" I would far rather
see any spare energy that folks here in c.l.a have going into resolving
practical issues of this sort.

How hard can it be to standardise a naming convention  ?

Kevin