From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,25d835bb9a4a003f
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!83.128.0.12.MISMATCH!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!xindi.nntp.kabelfoon.nl!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 06 Nov 2009 13:38:43 +0100
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Types,
 packages & objects : the good old naming conventions question
 (without religious ware)
References: 
 <561e0a4a-c6c0-42db-9f31-a70f4eae1ed9@a21g2000yqc.googlegroups.com>
 <hce79b$daf$1@aioe.org> <ygeocnohy02.fsf@hugsarin.sparre-andersen.dk>
 <u4ope4pqa.fsf@stephe-leake.org>
 <Xns9CB636112C917pcc482719gmailcom@198.186.192.137>
 <u1vkdrert.fsf@stephe-leake.org>
 <y-Odnak8_-myrm7XnZ2dnUVZ_s2dnZ2d@earthlink.com>
 <uskcsne3h.fsf@stephe-leake.org>
In-Reply-To: <uskcsne3h.fsf@stephe-leake.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4af418d8$0$7633$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 06 Nov 2009 13:38:48 CET
NNTP-Posting-Host: 9e02e8ad.newsspool1.arcor-online.net
X-Trace: 
 DXC=k^Y7TH1f`V1TQL:hoD@>T?ic==]BZ:af>4Fo<]lROoR1<`=YMgDjhg2Hbm@c@?m5g=PCY\c7>ejV8^=CSEl^`L<8ooTgmIf?378
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:9014
Date: 2009-11-06T13:38:48+01:00
List-Id: <comp.lang.ada>

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?