Wells and bads of the Rosen convention for OO like in Ada

Wells and bads of the Rosen convention for OO like in Ada

[Hibou57 (Yannick Duchêne)]

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 “ child
package ” 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 “ Instance ” 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 “ 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 ”. 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 “ 3 A convenient naming convention ” ).

[ 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.

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