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

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

On 11/7/09 6:49 AM, Stephen Leake wrote:

> One reason to use "_Type" is precisely _because_ it means "Ada type";
> there's no need to   wonder about what it means.

But the language meaning of "type" does not help with
the mentioned Message_Type_Type?
If I stubbornly follow your conventions as I understand them,
I'd have to write

   procedure Something (Message_Type : in Message_Type_Type);
or
   procedure Something (Message_Type : in Message_Types.Message_Type);

wouldn't I?  (I speculate that one could add a remark about
first class type objects here, as per Dmitry's suggestion.
More confusion.)


>>>>>> 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.
>
> So the case is not important; why did you introduce it?

The "String : String" part of the declaration means
  -object-named-String- : -type-named-String-
in Eiffel.  The very same word names both the
object and the type.  Characters case is important to the
reader, however (you have mentioned GNAT's warnings).
The writer may like to use case distinction to "disambiguate"
the same sequence of letters.  That's fine as long as you
live in a single universe of formal names, like when you are
working on the same set of Ada programs for months, and
never need to look elsewhere.


> In another post, someone said Eiffel required<>  around types; is that
> not true?

I mentioned Dylan where you would write string : <string>;
In Eiffel, and in hypothetical 2-namespace-Ada you write STring: STring,
if you want to. The visual difference is none.  Is the difference in
meaning perfectly clear in the body lines following the declaration?


> The point, as always in this discussion, is to save time making up
> separate names for types and objects.
>
>>> 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?
>
> Good programmers will just find it natural; why introduce twisted
> programmers into this?

OK, I thought that the design of a general purpose programming
language, together with the naming conventions surrounding it,
should be manageable by a general public of programmers, not just
"programmers who find this natural" =:def "good programmers".
Some good programmers, in fact language makers,
have made String : String impossible.  Supposedly, then, they
did not deem String : String a natural thing, even though they
were good programmers.

Here is an analogous example.
The argument (be a better programmer if you want to use our
language properly) is popular.  Whenever I had the courage to
mention that there are sharp corners in C and that,
therefore, we should be expecting these corners
to cause trouble, I heard it: programmers causing trouble
in C programs lack education! Well...
Proof of trouble is the weekly CVE report about C programs
and the type "int".  That's am empirical fact.  QED.

Is it an empirical fact that most programmers lack education?
Or does C have some dangerous imperfections?
The typical response is a exaggeration of your question: Why count
stupid non-C-knowing less than excellent programmers
in the select set of programmers-finding-C-natural who
know by heart the C standard and the compiler documentation?
("Because we live on planet earth!" is what I think, then.
"A language, or a naming convention, should respect this fact.")

Before turning back to Ada and naming conventions, let me
stress the analogy, regarding Ada programmer skills.
What about C programmers who are writing programs even
though they don't know every detail about C's "int"?
They are writing programs controlling machines that
affect our daily lives.  Should they not?  Should we
shape a language and conventions around the idea that "int"
is fine in the hands of brilliant programmers and that
other programmers should seek different occupations?
In any case, the above speakers will not accept the group of normal
programmers as a premise; mostly because doing so will show
C's imperfections when in the hands of imperfect programmers,
*to* *a* *degree* that is largely caused by C---it could be
less (which is why Cyclone is different, I should think).
Those speaking in favor of C's "idiosyncrasies" like "int" deny
the normal situation of imperfect programming...
This is why I am skeptical of naming conventions that need
twisted knowledge, like List : in out List.

My claim is that if Ada allows List : in out List, then there
will be a growing number of programmers who "save time making
up separate names" and routinely use T : T.
To support this claim, I think I can point at another time saver:
Anonymous "access" was introduced with Ada 2005.  People
like it.  One reason is that it saves time making up
pointer type names.
(Viz. why, instead of declaring pointer types, not just add Foo*
and &Bar like we are used to?  Of course,  I meant "X : access Foo;"
and "Bar'Unchecked_Access"?  Easy.  Saves time.)

IMO, the effect of naming conventions is first and foremost an
effect on human Ada programmers, caused by human programmers.
The language definition will influence naming conventions,
but this is accidental.