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.73.229 with SMTP id o5mr12085355pbv.7.1329210520008; Tue, 14 Feb 2012 01:08:40 -0800 (PST) Path: wr5ni23404pbc.0!nntp.google.com!news2.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: Tue, 14 Feb 2012 10:08:37 +0100 Organization: Ada @ Home Message-ID: References: <4f355230$0$21451$ba4acef3@reader.news.orange.fr> <1sx3fy79wys5s.1723nejowbg76.dlg@40tude.net> <15fgcngmgl41e$.113i7gtuwpwpv$.dlg@40tude.net> <12sbwz7m0r1qx.1pbp0ox3jr36s.dlg@40tude.net> <1nsv5nr9t05qd$.4u7741n9thcp.dlg@40tude.net> NNTP-Posting-Host: XZfFzKekCOFJcoZatuLArw.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-14T10:08:37+01:00 List-Id: Le Mon, 13 Feb 2012 22:02:17 +0100, Dmitry A. Kazakov = a =C3=A9crit: >>> package Units.Base is >>> Current : constant Unit; >>> Luminescence : constant Unit; >>> Temperature : constant Unit; >>> ... >> This is a good example, but still not a singleton, > > That was an example of singleton values. That's an example way to declare symbols. I feel singleton as constant a= re = apart (I use this too). Interesting topic, but would drift from naming = conventions. >> that's a specification, there is no need for an instantion here. > > This one for singleton objects: > > package Standard_IO is > Input : File_Type; -- Assuming File_Type limited > Output : File_Type; > Error : File_Type; > > Here is an example for singleton type: Personally, I prefer functions instead of this (don't want to comment mo= re = on that, would drift from naming convention too). >> About package holding singleton really holding singleton, like say a = Log >> package which would create a singleton file "Log.File" objct, I belie= ve >> that's not good for re=E2=80=91usability (ex. what about multiple tas= k?). Better >> provide a type with a constructor, > > Constructor =3D constructor or constructor =3D constructing function? = The > latter is bad design. I never get into trouble with this. If I am likely to get into troubles = = with it, I would like to know before it happens and have a chance to = prevent it before, obviously. On the mean time, I'm not a big tagged typ= e = user, and feel to understand your objections to it, mainly applies to = tagged types hierarchies. I would enjoy some pointers on the web on this= = topic. However, as long as I think "creation function", there are little= = risk I will get surprised with Ada's creation functions. > As for the example with log file, it is better not to expose it: > > package Logging is > type Category is mod ...; > Warning : constant Category; > Error : constant Category; > Info : constant Category; > Any : constant Category; > ... > procedure Log (Event : Category; Text : String; Stamp : Time :=3D = > Clock); > ... > end Logging; I agree (as a side not, I would also add a Source parameter to this :-P = ). >> What lacks for me here, is some paper with in deep talks about naming= >> convention in numerous ways. > > J-P provided one. He is one, whom opinion you can always trust (even i= f = > you disagree). I trust his paper, and read the one he pointed since long. As you probab= ly = noticed, I use the convention he pointed to, with just a tiny variation.= = Still does not cover enough of my concerns. And by the way, although I = trust him, I don't necessarily have to always agree with him: a good = practice is like a good spelling to me, the good spelling of a word = depends on the language (a word well spelled in a language is no good in= = another language, what ever how much it is well spelled in its original = = language); similarly, a practice is likely to apply fine in a context = where a set of other practices also applies. And this depend on the targ= et = and applications among others criteria. Anyway, the paper he pointed to, although valuable, does not cover the = questions I raised (but make me raise these questions in some way!). And= I = found no deeper papers on the web, except the ones from J.P. Rosen and = some Quality & Style Guide for Ada (unfortunately, I don't adhere to mos= t = of the naming conventions from this Quality & Style Guides). That's why I am experimenting during the opportunity of a short enough = application, to not have to experiment later on a bigger one (would = inevitably drives to hard disappointments). >> If a container type, named Container_Type can provide itself the type= = >> for >> its index. How can you refer to it, if not via some expression, like >> "Container_Type.Index_Type"? > > T'Index. Note that this is not an expression proper because in a = > statically > typed language the algebra of types is separated from the core (object= ) > language. The type and type-valued operations are not the first class > citizens. Types in Ada have a meta language with rudimentary expressio= ns = > of > its own. Yes it should be extended a bit, but not too much. Otherwise = you > could lose the property of being statically typed. Yes, I was wrong when I used the word "expression" for that purpose. T'Index vs T.Index may be an interesting topic, but an extrapolating one= = (as Ada is actually not this way) I don't want to go into now. Well, I will go on with my "Run"/"Apply"/"Value"/"Evaluated"/"Get" and s= o = on, with the hope I will end into something stable and satisfying with = clear enough definitions. -- = =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