Re: Convention for naming of packages

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

Le Fri, 10 Feb 2012 18:09:00 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 10.02.12 16:07, Yannick Duchêne (Hibou57) wrote:
>
>>    Object : constant Object_Type := Object (Param);
>
> (1) Does Object do anything? Does it, for example, make an object
> from Param? (2) Is there some kind of relationship between the
> function Object and its Param? (3) Is Object different from
> Object_Type--other than being a function, not a type?

No, it really returns an object and do nothing else (pure functions). I  
may be wrong with the choice of “Param” name. Better think of it as:

    Object : constant Object_Type := Object (Object_Of_Another_Type);

Object may returns/*be* an attribute (which may not really exist in the  
full view of the type if that's an opaque type) of its parameter(s). Some  
of these attributes may be kind of view. Thus, providing Instance_Type is  
defined, you may have things like:

    function Attribute_1 (Instance : Instance_Type) return Attribute_1_Type;
    function Attribute_2 (Instance : Instance_Type) return Attribute_2_Type;
    function View_1 (Instance : Instance_Type) return View_1_Type;
    function View_2 (Instance : Instance_Type) return View_2_Type;

For attributes, I though about something like a Get_ prefix, which is  
similar in some way to the Make_ prefix you suggest. But I want to avoid a  
prefix if possible. As I want a constant convention, this would mean using  
Get_ or Make_ everywhere. If I wanted to use Get_ only where conflict are  
likely to occurs, this would be weird and drafty (some function will have  
a Get_ prefixed, some others won't… not clean). Moreover, and as you later  
mentioned arrays, I would like to keep the ability to use the same  
convention for arrays and functions, as I see arrays as just a special  
kind of function and don't expect to emphases any distinction between  
arrays and functions. If ever the function was implemented with an array,  
which would be named Make_Something, this would be weird too.

Similarly, for views, I though about an As_ prefix. Being far less common  
and short while still correct english, this one could be OK and I don't  
mind for an As_ prefix. Having something like this would looks natural  
enough:

    View_Name : constant View_Name_Type := As_View_Name (Instance);

If a view may be seen as a special kind of attributes, the reversed is not  
true. I cannot name all attributes like this. So this would really be OK  
for views, and only views.

Function returning attributes, thus, accessors, are far more common. So a  
Get_ prefix would not be welcome. And this make it too much looks like an  
action, while the mentioned function are supposed to be pure.

For subprograms setting value, I don't mind to use a Set_ prefix  
everywhere, this looks natural, not bloating, and that's another story,  
there is no kind of conflict with object names here.


> When I imagine a function to be a table, the parameters and the
> result being the columns, I sometimes find a good name for
> the whole thing, in context.

What I want to avoid, is to think of a context which is too much specific  
and choose a name on that basis. That would mean the package specification  
may change each time an implementation create a context with conflicts.  
The package specification have to be designed with use case in mind, but  
should not be changed for each context which would occur later.

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