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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,CP1252
Path: 
 g2news2.google.com!postnews.google.com!j19g2000yqk.googlegroups.com!not-for-mail
From: =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?=
 <yannick_duchene@yahoo.fr>
Newsgroups: comp.lang.ada
Subject: Wells and bads of the Rosen convention for OO like in Ada
Date: Mon, 2 Nov 2009 23:11:52 -0800 (PST)
Organization: http://groups.google.com
Message-ID: 
 <8df1259e-081f-4e56-99e7-3831053c430a@j19g2000yqk.googlegroups.com>
NNTP-Posting-Host: 86.75.149.226
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1257232312 29269 127.0.0.1 (3 Nov 2009 07:11:52
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 3 Nov 2009 07:11:52 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: j19g2000yqk.googlegroups.com; posting-host=86.75.149.226;
	posting-account=vrfdLAoAAAAauX_3XwyXEwXCWN3A1l8D
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
	fr),gzip(gfe),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:8950
Date: 2009-11-02T23:11:52-08:00
List-Id: <comp.lang.ada>

Forewords : This thread is partly splitted from another one about
naming convention. This split is done according to a Stephen Leake's
suggestion, to not mix different things. It was a part of a thread
which among other subjects, attempted to talk about a design scheme. I
had started with some comments about it, and have another one today,
which seems important.

The following patterns from Rosen (see below), does not seems =93 child
package =94 friendly. Some people like to use a well known restriction
in program text : a declaration must not hide an outer declaration.
Many tools provides a way to enforce this design principle, GNAT and
AdaControl each do, and I suppose many others.

Kept apart any comments about the choice of =93 Instance =94 as the name
of the main type (which be good or not) and just talking about the use
of a common name for all main type names : it ends into trouble with
child packages when a child package derives the main type of its
parent package. This is not a program text error, this is fully legal
in Ada, but this conflict with an important design principle.

Original part follows ( for context : was commenting some stuffs in
http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1
)

------------------------------------------------------------------

Now another stuff, still about naming convention :

This Chapter 3 also introduced two main naming convention schemes,
one
which seems to comes from who-know-who, and one which comes from JP
Rosen.

At first sight, I was a bit surprised by the one suggested by JP
Rosen. In short, I silently though =93 all main type defined in a
package has the name Instance, and its class wide view has the name
Class... this is the least expressive things one may imagine, I don't
want this =94. But later, I figured out that in practice, this may be
indeed relevant because this is not the name of the type which
identify what it is, but rather its package name. First, a type is
nothing alone, it makes sense associated with a set of associated
method only, and the set of the type + its methods, is identified by
the package, so the package makes sense, more than the type does, so
yes, the package name is the first thing which requires a meaningful
name, not the type. Secondly (not less important), for people who
like
to not Use, the type name is just a component of a package, and thus
its name can be used as the name of something which always appears
with its context, the package, just like what it is with the
component
of a record. One should not choose the name of a record component the
same way he/she choose the name of a standalone instance, like a
variable. So finally, what first seems to me a convention to
obviously
avoid, appeared to me, to be the best one. Note : to go further, JP
Rosen explains in a paper, how this convention is also fine for
people
who Use : http://pagespro-orange.fr/adalog/publicat/naming9x.pdf
( see
at the end of =93 3 A convenient naming convention =94 ).

[ some comments dropped ]

I do not really agree with the choice of
Instance suggested by JP Rosen, which, as the name say, mean an
instance, what a type will never be.

But in the overall strategy, names choices kept apart, the Rosen way
seems good, and would just need to be completed with a few more
standard prefix and suffix.

------------------------------------------------------------------