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

[Stephen Leake <stephen_leake@stephe-leake.org>]

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

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

Yes. This is the only special case, and usually I just stubbornly
follow the convention. You get used to it.

Another choice is to use Message_Label instead; 

   procedure Something (Message_Label : in Message_Label_Type);

>> In another post, someone said Eiffel required<>  around types; is that
>> not true?
>
> I mentioned Dylan where you would write string : <string>;

Ah, sorry for the confusion.

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

No, there are times when either an object or a type could be used, in
attributes. Which is probably why Ada has a single namespace.

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

Yes, for good reasons.

> Supposedly, then, they did not deem String : String a natural thing,
> even though they were good programmers.

That's a stretch! Avoiding actual ambiguities is a better reason. But
I don't presume to read their minds. It would be interesting to read
some rationale on this; I don't think there is any in the Ada Language
Manual. 

> 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 undereducated programmers, by definition.

> They are writing programs controlling machines that affect our daily
> lives. Should they not? 

They should 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? 

No, we should shape languages that are easy to learn.

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

And why Ada is different.

> Those speaking in favor of C's "idiosyncrasies" like "int" deny the
> normal situation of imperfect programming... 

I don't know how "normal" it is to be programming in C and not
understand "int". I would hope it is not common at all!

> This is why I am skeptical of naming conventions that need twisted
> knowledge, like List : in out List.

I deny that this is "twisted"; that was the point of my response.

It makes perfect sense in English; we often use the same word to refer
to an item or a group. More commonly we use a plural form, but often
the plural form is the same as the singular. "List : Container" is no
better and no worse in English.

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

Yes! Then we will have more time for other things, like coming up
with good names for the other parameters.

You seem to be implying that this is a bad thing; what, exactly, is
the downside?

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

'Unchecked_Access is _not_ the same as as 'Access. Introducing bogus
arguments is not a good arguing tactic.

What is your point here? You seem to be implying that anonymous access
types are bad, but you don't say so. I disagree that they are bad.

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

Yes, no one has said otherwise.

In this case, the fact that the language design has a single namespace
for objects and types leads to the need for a convention to
distinguish the two.

I argue for a simple mechanical convention; append _type to type
names.

Others argue for a complex time-consuming convention; come up with
different names.

Others also argue that types and objects should have names that differ
by more than a suffix for other reasons. Several attempts have been
made to explain those other reasons; as I understand it, they all come
down to this:

    Names should convey as much information as possible, thus they
    should be domain-specific whenever possible. Thus the natural
    names for objects and types are different in many situations.

To which the reply is:

    When the domain is very general, very general names are
    appropriate, and the natural object and type names are the same.
    Then _Type (or some similar noise) is necessary.

One could then suggest a relaxed convention:

    Append _Type if the type name is very general, use a
    domain-specific name otherwise.

I never seriously considered the latter; it involves deciding whether
a name is "very general", which is even harder than coming up with
different names. It's far easier to just use _Type.

Also, I prefer writing reusable code, which tends to be
domain-independent. If I'm working on robots, and I need a vector math
package to compute the robot positions, I don't call it
robot_position_vectors, I call it vectors. And it's generic in the
floating point type, which is just named Real_Type, not Meters,
or Radians, or Positions.

Concrete objects in the robot code are call Pos_Joint_n, Pos_Tool,
etc. Parameters to subprograms tend to have more generic names.

-- 
-- Stephe