Types, packages & objects : the good old naming conventions question(without religious ware)

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Hibou57 (Yannick Duchêne) wrote:
>>
>> An example trap (to me at least) : what about a type which would seems
>> obviously named Size and a parameter which seems obviously named
>> Size ? X would surely not be OK, neither Item.
>
> If Size is the best name for the parameter, and assuming this a
> numeric value, then I'd call the type Size_Value.

Why not follow the typical convention, and call the type Size_Type?
The type name occurs in fewer places, so it's less noise to modify the
type.

>> An idea may be to get a more or less close synonymous (like Count...
>> not very good) for the parameter for which one may naturally be
>> tempted to name Size. But this seems (and is) a work-around, and if
>> the word “ work-around � really legitimately applies on that
>> situation, this means there is a trouble (not natural, at least). Why
>> the work around will probably applied on the parameter ? Because the
>> parameter comes later when the type definition is already introduced
>> (in the worst case, it may be tempting to change the type name). This
>> latter detail makes us to come to another aspect of the trouble :
>> choosing a practicable type name, may requires an amount of prediction
>> over what instance names may be.
>
> I think that you shouldn't be writing anything until you've decided on
> the type and its operations, including their parameters.

That's not possible, even in principle. You need use cases in order to
design a good type and operations.

--
-- Stephe

dhenry <tfc.duke@gmail.com> writes:

> I'm working on a "real" project and the convention we have chosen is
> to use suffixes _Type, _Array_Type and _Access:
>
> type Foo_Type is private;
> type Foo_Access is access all Foo_Type;

I use Foo_Access_Type for this.

> type Foo_Array_Type is array (Positive range <>) of Foo_Type;

I use Positive_Array_Foo_Type for this last one.

> We use simple rules, so that _Access can be either used for an
> "access", and "access all" or an access on a 'Class. If we need both
> class-wide access and simple access, we can use _Class_Access but it's
> not hard-written in our coding standard rules. This may not be
> rigorous, but we're fine with it because it's simple (when we decided
> about our coding standards, we didn't want to produce dozens of pages
> of rules).
>
> However there are some drawbacks, like how to name a variable which
> should be "message type" (an integer identifying the kind of a
> message). We can't use Message_Type, so we use Message_Typ (which is
> of type Message_Typ_Type). That's not pretty at all.

Yes, this case is a problem. I just use Message_Type_Type, and live
with it.

Apparantly in Dylan, that would be Message_Type for the object, and
<Message_Type> for the type. I like that better.

--
-- Stephe

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> dhenry wrote:
>>
>> I have a question for people not using any suffix like _Type or _T or
>> whatever: how do you name your access types? Do you allow here to use
>> a suffix?
>
> The objection is not to suffices; it's to suffices that add no value,
> which is true of _T[ype]. I personally like _Ptr for access types; on
> my current project the guideline is to use _Handle if there isn't a
> better name.

We happen to think _Type adds a lot of value; it saves effort during
writing and reading code. I agree it doesn't add any intrisic meaning
to the word, but that's not the only kind of value that's important.

--
-- Stephe

On 31 oct, 13:21, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> > type Foo_Type is private;
> > type Foo_Access is access all Foo_Type;
>
> I use Foo_Access_Type for this.

What's your reason to use Foo_Access_Type instead of Foo_Access ?
Is that because of objects named Foo_Access ?

(just wanted to know)

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:

> Remain nouns : they may match either object of types, just because the
> natural language does not make this distinction. Indeed, in every day
> life, we are not talking using type and class concepts (neither our
> ancestors does).

This is an interesting point.

There are some cases of English nouns that are by definition groups; a
gaggle of geese, a pride of lions. But there is no general convention
for this.

I don't know enough other languages to say whether this is a universal
truth about human languages.

> Is this mark very important to be standardized ?

Maybe for Ada 83; it is too late now.

--
-- Stephe

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:

> On 31 oct, 13:21, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> > type Foo_Type is private;
>> > type Foo_Access is access all Foo_Type;
>>
>> I use Foo_Access_Type for this.
>
> What's your reason to use Foo_Access_Type instead of Foo_Access ?

Just so the convention "all types end in _Type" is universal. That
helps when building tools that generate code, like Auto_Text_IO.

I'm also more rigid than a lot of people when it comes to rules.

> Is that because of objects named Foo_Access ?

I rarely do this; I use "Foo" for either a Foo_type object or a
Foo_Access_Type object, unless I need both in the same scope. Even
then, I usually use _Ptr, not _Access.

But it is a valid reason for Foo_Access_Type.

--
-- Stephe

Stephen Leake schrieb:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

>> When you see
>>
>> Append (List => List, Element => Element);
>>
>> you don't really know what's being appended to what.
>
> In a purely generic context, like in the body of
> Ada.Containers.Indefinite_Doubply_Linked_LIsts, that is precisely what
> you should know.
>
> What's wrong with that?

First, few people write purely generic code.

Stepanov et al. do. You do. Their admirable work has nevertheless
created new words in a new anguage by way of overloading.
(Can I suggest the name Techlish ?)
Example:
Combine "push" and "onto the back end" to have a mathematician
from Moscow create the word "push_back" for that. To me,
that is 90° off, never mind. (Just a speculation about the
origin of push_back. Absolutely no offense intended!)
And the concatenation "push" & "_back" is about the linguistic
support for the specification of meaning in STL programming
there is!

Unfortunately, when you work for some time on one subject,
its context becomes familiar to you---but not to others;
what is more, and as regards Ada.Containers work, is that the STL
and other generic programs revolve all around (a) generic algorithms,
(b) a certain machine model. The machine model is necessarily
of its own abstract nature. It is the starting point
for programming solutions using generic algorithms. Unfortunately,
neither the STL nor other libraries offer but internally sensible
names. They all force us to switch from our domain to the
generic machine. There is a gap in naming mechanisms; everything
is lumped together in slang names and most abstract, fluffy terms,
full of allusions to the theory behind, but lacking a real
mechanism that links the generic composition with the rest of
the program. Name wise. We'd need that in order to bridge
the gap between the two naming conventions.

There is therefore potential for tons of questions if all
a "non-generic" programmer sees is "List" or "Size" in all
sorts of places in a program. These words should be endemic
among generic library authors, yes. But why anywhere else?


> 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 think the ease argument will be interesting if it becomes
clear what the Op_N stand for, respectively.

The third line is notably not overloading the parameter name
"List" and the type name "List".

Cf. valid Eiffel:

local
string: STRING
do
... -- more uses of string and STRING. Or StrINg.

(Somewhat at odds with the 1-name-rule of that language.
I have only a single name space in my brain...)
Is this example as confusing than Op (List : List)?

Stephen Leake schrieb:

> Nonsense; it is _precisely_ what I want; a list of abstract objects.
>
> You can't avoid the naming problem by changing the context!

But there should be better ways to resolve the naming problem
when changing context. Better than being unspecific, that is:
it sure is possible, if redundant, to give a hint to the
context.

> Here are the similar definitions from
> Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start
> arguing that is a bad abstraction.

No, though it is perhaps notworthy that IIRC the container
type's name used to be "Container" in every package in some
earlier editions. (I couldn't resist saying some more on
names and abstract programming in another reply.)


> Note that it uses _Type for Element!

I think Element_Type was not chosen in order to take sides with
the _Type convention.


> How is that better than this:
>
> package Ada.Containers.Indefinite_Doubly_Linked_Lists is
>
> type List_Type is tagged private;
>
> generic
> with function "<" (Left, Right : Element_Type) return Boolean is <>;
> package Generic_Sorting is
>
> function Is_Sorted (List : List_Type) return Boolean;
> end Generic_Sorting;

There are fewer occurrences of "List" that need disambiguation.
But I'll happily leave it to that empirical study of the effects
of naming conventions whether other solutions work better or
worse.

>> (Rules here: Bits _of_ something, sensor _of_ something,
>> these are examples following Tom Moran's comment, if I'm
>> not mistaken. Names Sensor and Bits are really quite abstract.
>> I would force them to be used for abstract types' names, at best.)
>
> Yes, if you have a specific context and a specific meaning, then you
> should use a specific name. The corollary is that if you have a
> generic context, you should use a generic name.

But is the generic context really unspecifiable, i.e.,
do we have to become vague in our naming?
We could state, using names, or adorned names, or ...,
that something is useful in many specific cases.
This fact is a distinguishing feature.



>[list]
>
> Who said this was a linked list?

Any programmer with a Lisp background will assume List is :-)

If what matters is the set of operations needed,
then is it not possible to specify a frame of reference
for this particular meaning of "List"?


> [SAL] "list" tends to imply some access order, meaning there is at
> least First, Next, Is_Done. Containers don't have those functions.

This is where conventions can cause problems.

package Ada.Containers.Hashed_Sets is
...
function First (Container : Set) return Cursor;

SAL and Ada.Containers differ in their approaches to the same problem,
both using the same names connected to incompatible set of operations...



>> generic
>> type Less_Equal is new Ordering with private;
>> procedure Sort (Container : in out Linked_List);
>>
>> Is anything lost here?
>
> Yes! You have lost the fact that this is a generic procedure that
> doesn't care about the internal structure of the list.

OK. But then, personally, I would have though that (or the
abstract linking you have mentioned) would distinguish a List.

> You have also
> lost the ability to specify the Order at run-time.

Why? Can't I instantiate with any Ordering type from
any block that happens to be visited at run time?


> And "less_equal" implies a mathematical sort. All I really need for a
> sort that produces a linear order is "goes_before".

"Goes_Before" a better name, then. Though it corresponds to "Less"
only, not "Less_Equal", doesn't it? (I'm desparately looking
for how the [= relation is pronounced. Not_After?)

>> I think Dylan made an attempt, at least if one is satified with "car"
>> being in a different namespace than "<car>".
>
> Clearly it's a different name; it's a different lexeme. That's
> the same as the _Type convention.

I think this is significant: Many of us care about lexemes
much less than digital computers in that we rather correct
oddities like spelling errors or <framings> in letter patterns.


>> I'd still not pick essentially the same name for object Car
>> and type Car though. Even if Ada had one namespace for types
>> and one for other entities. An object is never the same
>> as a type, therefore it should be possible to distinguish
>> the difference using words.
>
> Yes! Car is distinguished from Car_Type, but List is not distinguished
> from Container. Thank you for agreeing with me .

OK, to me, Car_Type is only minimally different from Car,
and not sufficiently. In particular, the difference carries
no meaning in either the objects domain, or in the comain
of the value sets of types.
(I guess we both would not write procedure Speed_Subprogram (...))


> Actually, I disagree with this statement; overloading types and
> objects is fine, since the language does make the distinction clear
> from context. In Dylan, I would use "car" and "<car>".
>
> It sounds like you don't like overloading in the first place. How
> about this:
>
> adding integers is never the same as adding float; it should be
> possible to distinguish the difference using words

OCaml does, though with a bit of black dirt only.

> So you don't like "+" (Left, Right : in Integer) and "+" (Left, Right
> : in Float)?
>
> If you do like operator overloading, how is that different from
> object/type overloading?

I don't like conventional operators in Ada programs,
and more so in C programs:
They create a huge set of problems when people think
they know what they are doing when writing "+".

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
news:uskcz6ahs.fsf@stephe-leake.org...
....
> 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).

Randy.

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
news:u8wet6ttv.fsf@stephe-leake.org...
....
>> I do not mean I'm surprised this convention is working fine with the
>> Ada standard packages set, I know there is probably a reason which
>> explains why it works in this one case :
>
> It works for the standard because people are very flexible, and can
> work around quirks like this while convincing themselves it's better.
>
> It would take less effort to use a package if all types followed the
> _Type convention. Then more people would have more time to write more
> Ada code, and we'd take over the world.

This note gave me a good laugh.

At one point, Matt had use "_Type" in all of the names used in the
containers. There are enough people who hate that convention that we ended
up changing it. I was surprised by that reaction: Claw uses "_Type" in about
95% of its types (there are few cases where other suffixes made the "_Type"
look like pure noise) -- and I don't recall anyone complaining. I would have
preferred to continue to use "_Type" in most cases, but it isn't that big of
a deal to me.

Randy.

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.

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> 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

Stephen Leake schrieb:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> 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);
....
> I meant easier in all senses; fewer compiler errors, fewer real
> errors, less development time.

What about the time needed to understand the program,
or to communicate its meaning, and be it just the outlining
of the don't-care parts absent from the naming scheme?

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

Here we are... You may know, but I don't; if I am important
as a user of your programs, I'd kindly ask you to have the
knowledge shine through the names.


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

In this case (two things we know: we have a list package and
a list type), it is possible instead to give, first,

package List is

type Container is private;

procedure Sort (Elements : in out Container; ...);

and, second, a rule that forces programmers to use a prefix
in clients, to make sure the type of "Container" can be seen
immediately:

procedure Some_Client
(<problem-domain-name> : List.Container; ...);

Left_Queue, Right_Queue : List.Container;



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

No, the argument is that a language allowing the same name
("string") to stand for different things, for both objects and
types, in the same scope will necessarily add another dimension
to the confusion space. Specifically, "string" and "STRING" do
not denote the same thing *even* *though* the language
Eiffel is case insensitive, like Ada. The lexical overlap
of names in separate name spaces plus the case insensitivity
add to to the combinatorial explosives in front of the
reader.
(Of course, in real life forcing good standalone names
are simply(*) is countered with "works for me".)

procedure Something (List : in out List; ....), with a
namespace for objects and another for types, just places
the burden of disambiguation on the reader. Yes, they need
to do that sometimes; the author might not forsee the
necessity. To me, it does not matter that the author of
Something happens to know which is which.

Continuing Dmitry's argument

package List_Package is

type List_Type is private;


function List_Function return List_Type;

end List_Package;

Here, I must choose List_Function because Ada lets me have
only one namespace. So I need to add noise, but
I (the author) know that the function is just
returning a new List, no need to think of a good name,
since I know what I am doing... What am I doing?

What would clients look like?

-----
(*) "Simply" is a trade mark of Betrand Meyer.
(There are simply too many occurrences of "simply" in
OOSC2 to think otherwise...)

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Stephen Leake schrieb:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> 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);
> ...
>> I meant easier in all senses; fewer compiler errors, fewer real
>> errors, less development time.
>
> What about the time needed to understand the program,
> or to communicate its meaning, and be it just the outlining
> of the don't-care parts absent from the naming scheme?

I don't understand why you are excluding the naming scheme. Naming
conventions are huge gain in understanding.

If I am reading a package that defines an abstract type List_Type, and
all primitive operations on List_Type have a parameter named List,
then I don't have to try to understand whatever name got used instead
of List.

>>> 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
>
> Here we are... You may know, but I don't; if I am important
> as a user of your programs, I'd kindly ask you to have the
> knowledge shine through the names.

The names of the Op_N, sure. The name of the List parameter is
unlikely to add any information.

If there is more than one List paramter (say for Copy, or Splice),
then they need better names, of course.

>> 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.
>
> In this case (two things we know: we have a list package and
> a list type), it is possible instead to give, first,
>
> package List is
>
> type Container is private;
>
> procedure Sort (Elements : in out Container; ...);
>
> and,

Why is this better? It's just a different convention. If you follow it
uniformly, it will be just as good as List : in out List_Type.

> second, a rule that forces programmers to use a prefix in clients,
> to make sure the type of "Container" can be seen immediately:
>
> procedure Some_Client
> (<problem-domain-name> : List.Container; ...);
>
> Left_Queue, Right_Queue : List.Container;

What if the problem domain is "any list"? We keep pointing this out,
people keep ignoring it.

List.Container is much longer than it needs to be. But that's the
"don't use 'use'" argument.

>>> 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.
>
> No, the argument is that a language allowing the same name
> ("string") to stand for different things, for both objects and
> types, in the same scope will necessarily add another dimension
> to the confusion space. Specifically, "string" and "STRING" do
> not denote the same thing *even* *though* the language
> Eiffel is case insensitive, like Ada.

That makes no sense. Ah; Eiffel has separate type and object name
spaces. So I don't understand the original example; what was the
point?

Yes, this is an example of name overloading. Overloading, like any
good thing, can be abused.

> The lexical overlap of names in separate name spaces plus the case
> insensitivity add to to the combinatorial explosives in front of the
> reader. (Of course, in real life forcing good standalone names are
> simply(*) is countered with "works for me".)

That is the argument against case insensitivity. I like GNAT's
solution to that; issue a warning when an identifier has different
casing than the first use.

> procedure Something (List : in out List; ....), with a
> namespace for objects and another for types, just places
> the burden of disambiguation on the reader.

Yes. But it is a very small burden, pretty much the same as having to
read _Type.

The syntax provides all the information necessary; Object : Type.

> Continuing Dmitry's argument
>
> package List_Package is
>
> type List_Type is private;
>
>
> function List_Function return List_Type;
>
> end List_Package;
>
> Here, I must choose List_Function because Ada lets me have
> only one namespace. So I need to add noise, but
> I (the author) know that the function is just
> returning a new List, no need to think of a good name,
> since I know what I am doing... What am I doing?

I don't understand your point. No one has suggested choosing generic
names for functions; clearly they need to indicate what the function
does. If this function returns a new empty list, I would call it
New_Empty_List.

Hmm. I guess you are pointing out that package names, subprogram
names, object names, and type names all share the same namespace.
Since we feel the need to add noise to types, why don't we feel the
same need to add noise to packages and subprograms?

The answer is we just don't .

There are far fewer package names than other names, and come from the
domain, so it's not hard to come up with unique names. Making them
plural and everything else singular works pretty well.

Subprogram names tend to be more specific than parameters of an abstract
type.

I sometimes have package names that collide with enumeration
identifiers:

package Root_Serial_IO is

type Supported_Cards_Type is (Motorola_1, Intel_1,
national_semiconductor_42);

type Device_Type is abstract tagged private;

...
end Root_Serial_IO;

then I want child packages with the names Root_Serial_IO.Motorola_1
etc; that causes ambiguities, and sometimes ends up being unworkable.

--
-- Stephe

On 11/6/09 11:14 AM, Stephen Leake wrote:

>> In this case (two things we know: we have a list package and
>> a list type), it is possible instead to give, first,
>>
>> package List is
>>
>> type Container is private;
>>
>> procedure Sort (Elements : in out Container; ...);
>>
>> and,
>
> Why is this better? It's just a different convention. If you follow it
> uniformly, it will be just as good as List : in out List_Type.

The convention differs in that none of the identifiers overlap.
For me, List and List_Type are just not different enough (the first
being a prefix of the second only in a very mechanical sense BTW):
I need to combine programs whose authors have followed
different naming conventions. In this case I have to take
responsibility for disambiguating all occurrences of "List"
WRT to their denoting a type or an object.

Yes, if one author chooses to name the package "List" and the
type "Container", another chooses type name "List", the situation
is equally imperfect. But at least, I feel like the authors
have picked names whose differences is more than a dry, formal
suffix like "_Type": the difference is in the "domain part" of
the type name.


>> second, a rule that forces programmers to use a prefix in clients,
>> to make sure the type of "Container" can be seen immediately:
>>
>> procedure Some_Client
>> (<problem-domain-name> : List.Container; ...);
>>
>> Left_Queue, Right_Queue : List.Container;
>
> What if the problem domain is "any list"? We keep pointing this out,
> people keep ignoring it.


procedure Some_Client (Any_List : List.Container; ...);
procedure Some_Client (Any_List : List; ...);
procedure Some_Client (Any_List : Sequence; ...);


This is what I meant by hinting to the domain. (It seems possible
to argue that the word "Any" has a role to play in type names.
I haven't seen "any" as part of a type name, though, only as a
standalone type name, in Eiffel.) "Any_List" is just explicitly
referring to "any list"; I find "list" for "any list" leaves
more questions to be asked, given the ubiquitous use of "list".
A resolution requires assuming that some convention can
decide on the interpretation.

At least, "Any", unlike "_Type" is not from the Ada language
vocabulary.


> List.Container is much longer than it needs to be. But that's the
> "don't use 'use'" argument.
>
>>>> Cf. valid Eiffel:
>>>>
>>>> local
>>>> string: STRING
>>>> do
>>>> ... -- more uses of string and STRING. Or StrINg.
> Ah; Eiffel has separate type and object name
> spaces. So I don't understand the original example; what was the
> point?

In a dozen or so lines of subprogram text, the sequence of
characters "String" can refer to two different concepts, in Eiffel,
when you have declared string : STRING, an object and a type.
The reader, on seeing "String" in the lines following the
declaration, is forced to infer from context which concept was
meant. Sure, this is possible, not even difficult if you know
the language, as every Eiffel compiler demonstrates. But I don't
want to assume the role of the compiler just to see what
"String" stands for.
This is name overloading of two language concepts in the
very same inner scope. Even when this if formally just
fine, what's the point?


> Yes, this is an example of name overloading. Overloading, like any
> good thing, can be abused.

Assuming separate namespaces for objects and types,
I can imagine programmers who find "string : STRING"
very clever. Or just a good match for some twisted programming
trick. Why make cleverness, or the appearance thereof,
easy to achieve?

For comparison, imagine a Prolog program that uses Yellow in the
parameter list and yellow in the definition. A Prolog fan knows
that "Yellow" is not bound AFAIK, since it starts with a capital
letter "Y"; "yellow", starting with a small "f", must have
been bound somewhere. In a sense, Yellow and yellow
live in different namespaces. The image of that definition
does confuse me, but I am not sure whether this style is
frowned upon in the Prolog community. I hope so.
The rule about upper case first letters for Prolog variables
has been criticized.

>> procedure Something (List : in out List; ....), with a
>> namespace for objects and another for types, just places
>> the burden of disambiguation on the reader.
>
> Yes. But it is a very small burden, pretty much the same as having to
> read _Type.

I have to disagree here, for reasons given here and in another post.


> Hmm. I guess you are pointing out that package names, subprogram
> names, object names, and type names all share the same namespace.
> Since we feel the need to add noise to types, why don't we feel the
> same need to add noise to packages and subprograms?
>
> The answer is we just don't .

True enough. Yet there are those who feel the need to not
add _Type to type names, too, at least when the suffix
is used to "free" that same name for objects nearby.