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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c39ad3e35a7690a9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Received: by 10.68.213.68 with SMTP id nq4mr4219452pbc.2.1328895680532; Fri, 10 Feb 2012 09:41:20 -0800 (PST) Path: wr5ni9367pbc.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Convention for naming of packages Date: Fri, 10 Feb 2012 18:41:18 +0100 Organization: Ada @ Home Message-ID: References: <4f354f2c$0$6567$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: 3Dnc1BsVLavoSxHR9zQiRQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/11.61 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-02-10T18:41:18+01:00 List-Id: Le Fri, 10 Feb 2012 18:09:00 +0100, Georg Bauhaus = a =C3=A9crit: > On 10.02.12 16:07, Yannick Duch=C3=AAne (Hibou57) wrote: > >> Object : constant Object_Type :=3D Object (Param); > > (1) Does Object do anything? Does it, for example, make an object > from Param? (2) Is there some kind of relationship between the > function Object and its Param? (3) Is Object different from > Object_Type--other than being a function, not a type? No, it really returns an object and do nothing else (pure functions). I = = may be wrong with the choice of =E2=80=9CParam=E2=80=9D name. Better thi= nk of it as: Object : constant Object_Type :=3D Object (Object_Of_Another_Type); Object may returns/*be* an attribute (which may not really exist in the = = full view of the type if that's an opaque type) of its parameter(s). Som= e = of these attributes may be kind of view. Thus, providing Instance_Type i= s = defined, you may have things like: function Attribute_1 (Instance : Instance_Type) return Attribute_1_T= ype; function Attribute_2 (Instance : Instance_Type) return Attribute_2_T= ype; function View_1 (Instance : Instance_Type) return View_1_Type; function View_2 (Instance : Instance_Type) return View_2_Type; For attributes, I though about something like a Get_ prefix, which is = similar in some way to the Make_ prefix you suggest. But I want to avoid= a = prefix if possible. As I want a constant convention, this would mean usi= ng = Get_ or Make_ everywhere. If I wanted to use Get_ only where conflict ar= e = likely to occurs, this would be weird and drafty (some function will hav= e = a Get_ prefixed, some others won't=E2=80=A6 not clean). Moreover, and as= you later = mentioned arrays, I would like to keep the ability to use the same = convention for arrays and functions, as I see arrays as just a special = kind of function and don't expect to emphases any distinction between = arrays and functions. If ever the function was implemented with an array= , = which would be named Make_Something, this would be weird too. Similarly, for views, I though about an As_ prefix. Being far less commo= n = and short while still correct english, this one could be OK and I don't = = mind for an As_ prefix. Having something like this would looks natural = enough: View_Name : constant View_Name_Type :=3D As_View_Name (Instance); If a view may be seen as a special kind of attributes, the reversed is n= ot = true. I cannot name all attributes like this. So this would really be OK= = for views, and only views. Function returning attributes, thus, accessors, are far more common. So = a = Get_ prefix would not be welcome. And this make it too much looks like a= n = action, while the mentioned function are supposed to be pure. For subprograms setting value, I don't mind to use a Set_ prefix = everywhere, this looks natural, not bloating, and that's another story, = = there is no kind of conflict with object names here. > When I imagine a function to be a table, the parameters and the > result being the columns, I sometimes find a good name for > the whole thing, in context. What I want to avoid, is to think of a context which is too much specifi= c = and choose a name on that basis. That would mean the package specificati= on = may change each time an implementation create a context with conflicts. = = The package specification have to be designed with use case in mind, but= = should not be changed for each context which would occur later. -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity