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

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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