Re: Convention for naming of packages

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 13 Feb 2012 19:10:41 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 13 Feb 2012 18:19:16 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>> 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;
>>    ...
> This is a good example, but still not a singleton,

That was an example of singleton values.

> 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:

task Scheduler is
   ...

(Though singleton types are always suspicious for bad design)

> 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.

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;

> 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).

>>> 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.
> I don't what kind of language construct you imagine, but I am pretty sure  
> these construct would requires dedicated keywords somewhere, some keywords  
> which would be the exact same as the names I am looking for.

Class in T'Class is not a reserved word. Neither Unchecked_Access in
X'Unchecked_Access is. Some Ada's reserved words were promoted for no good
reason, but rather because of Ada 83 tradition.

>> 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.

> Seems you are wishing Introspection in Ada. Funny for someone who dislike  
> languages which provides it ;-)

As I said it is a delicate balance. You can have it neither all nominal nor
all inferred.

> 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de