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,UTF8 Path: g2news2.google.com!news1.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Types, packages & objects : the good old naming conventions question (without religious ware) References: <4ae9dade$0$6551$9b4e6d93@newsspool4.arcor-online.net> <561e0a4a-c6c0-42db-9f31-a70f4eae1ed9@a21g2000yqc.googlegroups.com> From: Stephen Leake Date: Sat, 31 Oct 2009 08:13:25 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) Cancel-Lock: sha1:lU1iC4YRyZk2lPwcDM8qQWAYu+U= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: b9ccd4aec29dfe197caa724095 Xref: g2news2.google.com comp.lang.ada:8918 Date: 2009-10-31T08:13:25-04:00 List-Id: "Jeffrey R. Carter" writes: > Hibou57 (Yannick Duchêne) wrote: >> >> An example trap (to me at least) : what about a type which would seems >> obviously named Size and a parameter which seems obviously named >> Size ? X would surely not be OK, neither Item. > > If Size is the best name for the parameter, and assuming this a > numeric value, then I'd call the type Size_Value. Why not follow the typical convention, and call the type Size_Type? The type name occurs in fewer places, so it's less noise to modify the type. >> An idea may be to get a more or less close synonymous (like Count... >> not very good) for the parameter for which one may naturally be >> tempted to name Size. But this seems (and is) a work-around, and if >> the word “ work-around ” really legitimately applies on that >> situation, this means there is a trouble (not natural, at least). Why >> the work around will probably applied on the parameter ? Because the >> parameter comes later when the type definition is already introduced >> (in the worst case, it may be tempting to change the type name). This >> latter detail makes us to come to another aspect of the trouble : >> choosing a practicable type name, may requires an amount of prediction >> over what instance names may be. > > I think that you shouldn't be writing anything until you've decided on > the type and its operations, including their parameters. That's not possible, even in principle. You need use cases in order to design a good type and operations. -- -- Stephe