Re: Convention for naming of packages

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

Le Mon, 13 Feb 2012 14:19:58 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> On the contrary, that's exactly what an abstract name do.
>
> Abstract to what? In first place it should abstract the context of usage.
The role of something in the structure it belongs to, is not the same as  
the role it may be given in a use case.

Ex. A file may be a source, a destination, a backup support, a memory  
auxiliary, and so on. In the package defining the file, to me, the type is  
just the type of the thing defined by the package.

A package defines either, a domain, some relationships, a process, an  
object type (at least to me), possibly some other high level concepts too.  
Let talk about a package defining an object, to keep one single example.  
An object type has methods for creation; you name it Create, not  
Create_XXXX_Type. A type has an instance type, I name it Instance_Type,  
not XXXX_Type; similarly, if it's tagged, I will systematically define a  
Class_Type. Some type may be named Element_Type, because that is their  
role if the package defines a container object. That Element_Type may be a  
Symbol_Type in some contexts.

The role in a structure in not the same as the role given in a use‑case or  
larger structure.

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.


> Does your name depend on where you are?
In formal terms, my name is not a name, it's an identifier (although not  
strictly unique in practice, as some name+surname pairs may be homonyms).

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