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

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

On 11/6/09 11:26 AM, Stephen Leake wrote:
> "Vincent Marciante"<vmarciante@decilog.com>  writes:
>

>> package sdgfkjasf is -- or whayever
>>
>>     type List is ...
>>
>>     procedure jsdfks (List : sdgfkjasf.List);
>>
>>     ...
>
> That's the first time I've seen that suggestion.

For objects, this is how task components are matched
with acceptor parameters in John Barnes's book (not
the exact same thing as object names and type names,
for sure, but the prefix is present):

    task body W is
      A: T;
    begin
      accept Foo (A: T) do
        W.A := A;
      end Foo;



> It's interesting why no one seems to have thought of this before.

My guess is that it has to do with expectations:
Many readers will have seen both X and X_Type as type names.
Consequently, both forms can denote a type in their expectation.
This expectation would have to be unlearned and replaced
with yet another expectation, a somewhat idiosyncratic one:
that X denotes an object and P.X denotes a type, as you
have outlined.
At first sight this seems better than _Type, since P.X
does not force the mixture of solution words like "X" and
"meta names" from the Ada language description like "_Type".

But starting from the first expectation, what really matters
is X.  How can we map exactly one meaning to exactly one
kind of entity presuming it is the direct name that matters?