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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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.74.201 with SMTP id w9mr10275022pbv.0.1329153558402; Mon, 13 Feb 2012 09:19:18 -0800 (PST) Path: wr5ni20774pbc.0!nntp.google.com!news2.google.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Convention for naming of packages Date: Mon, 13 Feb 2012 18:19:16 +0100 Organization: cbb software GmbH 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: trR2WuoGABtEWk7YPfvgdQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Date: 2012-02-13T18:19:16+01:00 List-Id: On Mon, 13 Feb 2012 17:24:12 +0100, Yannick Duchêne (Hibou57) wrote: > Le Mon, 13 Feb 2012 16:11:49 +0100, Dmitry A. Kazakov > a écrit: > >> On Mon, 13 Feb 2012 15:20:30 +0100, Yannick Duchêne (Hibou57) wrote: >> >>> An object type has methods for creation; >> >> A singletone may not have such method. Semantically, you should not be >> able create a singletone explicitly. > > Seems my wording was unclear. I meant a package describing, specifying (by > Package, I mean the interface, not the body) something. A package is not > an instance of the object if discribes (when its purpose is to describe an > object), it defines it. It is a quite uncommon use anyway. I mean to have a package of instances of some types. But certainly if that happens the instance always have meaningful names rather than "Object". E.g. package Units.Base is Current : constant Unit; Luminescence : constant Unit; Temperature : constant Unit; ... I think that any thing worth a name can be named. If not, that is because some language deficiency. >>> The example with Element_Type which may be a Symbol_Type in some context, >>> explains why I said this may be compared to genericity. >>> >>> Static genericity seems adopted without too much objections in the “crowd” >>> of Ada application authors. >> >> Static polymorphism is OK so long the semantics of overloaded entities is >> same. The semantics of Element_Type is? Element + type? That looks far >> too thin. > The semantic may be thin, if the semantic is thin, then its specification > cannot be said too much thin for the sole reason it's thin. > > Element_Type would be Element + Type, as you say, and also what appears as > the second parameter of an Add method. Its presence as the second > parameter of Add defines what Element_Type is (not just its name “Element” > and its Type status in the Ada source text). It is a language deficiency here, namely the generics. If the type of the class (of the container type) could be properly typed, you would not need to have meaningless names in meaningless packages the only purpose of which is meaningless instantiation. But even with generics, it is another deficiency that the element type (or the class of) cannot be asked from the container type it belongs to, as well as the type of the index and the type of sets of indices. Yes, I am aware of dangers of type inference. Anonymous access types was an error. But T'Class was right. It is a very delicate balance each time. So far, it seems to me that element and index types should be anonymous. Anyway, outside the stuff caused by the generic plague, and container-member-index relationships (record types belong here as well), names can and shall be meaningful. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de