Re: Convention for naming of packages

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

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  
> <mailbox@dmitry-kazakov.de> 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