From: Randy Brukardt on
"Stephen Leake" <stephen_leake(a)> wrote in message
> Here are the similar definitions from
> Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start
> arguing that is a bad abstraction.
> package Ada.Containers.Indefinite_Doubly_Linked_Lists is
> type List is tagged private;
> generic
> with function "<" (Left, Right : Element_Type) return Boolean is <>;
> package Generic_Sorting is
> function Is_Sorted (Container : List) return Boolean;
> end Generic_Sorting;
> end Ada.Containers.Indefinite_Doubly_Linked_Lists;
> Note that it uses _Type for Element!

If anyone cares, that's because we used a form of Stephen's rules for naming
these. In this case, we determined that the best name ("Element") should be
reserved for the operation, as the operation will likely be used many times,
while the formal type name is hardly ever written in client code (just as a
name in the instance) -- note this ties into one of the previous threads
here. We considered using longer names for the operation like "Get_Element",
"Read_Element", etc., but those just made the name longer without adding
enough additional information. After all, an important rule is to make names
long enough to capture all of the critical information, but no longer
(because there is a point where names get too long for readability).


From: Hibou57 (Yannick DuchĂȘne) on
May be a step to help to go forward : I remember that I oftenly saw,
in some Windows API documentations, something which I feel nice : some
type declarations were coming with a suggested prefix to be used as a
tag indicating the type in the purpose of the Hungarian notation. I'm
not thinking about mapping this exact thing, but it make me thing
about a similar idea.

This may be cool, to provide a small list of suggested names for
concrete instance of generic packages, object instances of a type,
derived type name, etc, when applicable. In a whole, the idea to
provide naming hints beside declarations, whenever a declaration is
subject to later instantiations or later derivations.

This does not solve the question exposed by this topic, but this may
be a tool to use in this area.
From: Stephen Leake on
"Peter C. Chapin" <pcc482719(a)> writes:

> Stephen Leake <stephen_leake(a)> wrote in
> news:u4ope4pqa.fsf(a)
>> Yes, but reading is also important. The _Type suffix is essentially
>> noise when reading; it's only there for the compiler, not the human.
>> So you want to read it as few times as possible, as well as write it
>> as few times as possible.
> This seems backwards to me. I could use a type name such as X72efY9 for all
> the compiler cares. The _Type suffix is most definitely for the human. It
> says, "Hey! This is the name of a type so keep that in mind when looking at
> this code."

Well, you can read it that way. But the original reason the _Type
convention got started (at least, as far as I'm concerned) is to solve
the problem of overlapping object and type namespaces.

This is illegal:

procedure (List : in list);

So we have to add noise to either the object or the type, to keep the
compiler happy. That's all there is to it.

> In the past I used _Type as a suffix for all of my types. However, there
> are times when that doesn't seem to fit. After all the standard types don't
> (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc).

The standard is Just Wrong. But we have to live with it.

-- Stephe
From: Stephen Leake on
Georg Bauhaus <rm.dash-bauhaus(a)> writes:

> Stephen Leake schrieb:
>> Op_1 (onto => list, element => object_1);
>> Op_2 (from => list, element => object_2);
>> Op_3 (container => list, element => object_3);
>> It's much easier if it's always "list => list".
> Well, ease as an excuse... I find it much easier to write
> C++, fast; C++ at some level is much easier and more
> permissive---easier until there is some odd crash
> and you look through the large combinatorial array of
> generic library names(!) in a long diagnostic message...

I meant easier in all senses; fewer compiler errors, fewer real
errors, less development time.

> I think the ease argument will be interesting if it becomes
> clear what the Op_N stand for, respectively.

If you start asking about what they stand for, you've missed the
point. I should not have to waste time thinking about that; I know
they come from the list package, so the type is List_Type, and the
parameter name is List. Now I can think about the _other_ parameters.

> Cf. valid Eiffel:
> local
> string: STRING
> do
> ... -- more uses of string and STRING. Or StrINg.

That is the argument both for and against case sensitivity.

-- Stephe
From: Dmitry A. Kazakov on
On Wed, 04 Nov 2009 19:33:58 -0500, Stephen Leake wrote:

> "Peter C. Chapin" <pcc482719(a)> writes:
>> In the past I used _Type as a suffix for all of my types. However, there
>> are times when that doesn't seem to fit. After all the standard types don't
>> (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc).
> The standard is Just Wrong. But we have to live with it.

Huh, it is not too late to introduce:

package Standard is
subtype Integer_Type is Integer;
end Standard;

But Know what? "subtype" looks awfully wrong! Should not it be
"subtype_type"? What about

type_type String_Type is
array_type (Integer_Type range <>)
of Character_Type;


Consider it this way, if _Type is felt appropriate then that is
semantically equivalent to types having a separate name space. The latter
could be introduced in Ada at any time, being fully backward compatible.

Dmitry A. Kazakov