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

["Vincent Marciante" <vmarciante@decilog.com>]

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

What I gathered was that the original chief language
designer constructed the language rules with a goal
of trying to drive/impose the necessity of "good"
program architecture and trying to prevent/discourage
"bad" program architecture and I think that the following
was one of the things that was to be promoted:

- separating (having in different packages) the declaration
of types (abstract data types) and object of the type.

I think that having two namespaces would have made
having both in the same declarative region easier
but that would only really come up for the type
and only one object (or as a yucky "workaround")
an array of them) declared together.  Clearly, whenever
there are two objects of the type, the simple name
of one of them _must_ be different than the name of
the type unless they are in different declarative
regions.  I think that separate object and type
namespaces would simply have been redundant.

Also, I showed that the "parameter of subprogram
declaration" case (which was the old example that
I brought up in an earlier message) is easily and
elegantly dealt with by the sjkdf.type_name construct
So, that there is really no need for two namespaces
but there also is really is no need for any overall
naming convention either!

As to why there is "File_Type" in Text_IO instead
of various Sub(File:Text_IO.File) declarations, I'd
for a couple of reasons) say it was just a "mistake"
due to expediency.  My reasons are:
(1) The big text_IO package was not part of the original
language, it was added (relatively quickly?) in order
to reduce the amount of generic instantiations that
would be required to do simple io. (2) The original
chief designer afterward acknowlegded/commented that
he thought that even having text_io depend on the
predefined "integer" was a mistake.

With all of that I am not trying to be be "diffinative"
in any way, I'm just putting out what I remember and
(though about) from earily on at the start of my use
of Ada.

I hope that at least some of what I wrote is at all
useful (and that none of it is inacurate!)


Vinny