Re: Convention for naming of packages

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Mon, 13 Feb 2012 22:02:17 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>>> 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 are  
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 more  
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 believe
>> that's not good for re‑usability (ex. what about multiple task?). Better
>> provide a type with a constructor,
>
> Constructor = constructor or constructor = 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 type  
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 :=  
> 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 if  
> you disagree).
I trust his paper, and read the one he pointed since long. As you probably  
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 target  
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 most  
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 expressions  
> 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 so  
on, with the hope I will end into something stable and satisfying with  
clear enough definitions.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University