Re: Convention for naming of packages

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

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's a specification,  
there is no need for an instantion here.

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, and if a file is to be shared between  
multiple "Log.Instance_Type" instance, then its up to the implementation  
to create allocate one and create association between the shared object  
and object created by users.

That's all small‑talks :-P

> I think that any thing worth a name can be named. If not, that is because
> some language deficiency.

I believe a language deficiency, if it really exist, always provide the  
filling of that deficiency first. I don't feel one here, even if I agree I  
may think the thing a different way with another language. A single thing  
is not a deficiency alone, it is a deficiency with respect to a whole. The  
whole seems rather Okay to me so far.

What lacks for me here, is some paper with in deep talks about naming  
convention in numerous ways. Most paper just talks about naming convention  
just as a quick overview. I see the deficiency here, not in the language  
(deficiency of culture of the language, not deficiency of the language).

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

Ada's reserved word "type", is not meaningless, it's an high level concept  
(so is obviously abstract). Or else I did not understand your words?

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

Will fall to the same comment as above anyway. Type would just play some  
of the roles of packages (not all roles, some roles), and you would need  
some way to refer to things. Here, you will be back to the need of some  
name to refer to it.

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"?

Or else have you something different in mind? Could you write‑down a tiny  
example using pseudo‑code to make it clearer?

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