Re: Beginners question: Compound types, how-to?

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

Le Wed, 03 Nov 2010 18:01:55 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 03.11.10 17:56, Warren wrote:
>
>> There is a good practical case for _Type, IMO. If Buffer_Type is defined
>> simply as Buffer, then we develop an inconvenient name clash:
>>
>>>     subtype Buffer is
>>>        System.Storage_Elements.Storage_Array (1..Buffer_Size);
>>
>> In use now:
>>
>> declare
>>    Buffer : Buffer;   -- hmmmm
>> begin
>
> What role does the object named Buffer play?
>
> It is a buffer, yes. Is it different from other buffers?
> How?  What lives in it?  How does the program use it?
>
> I believe answering these questions leads to a better name.

Please, read all, up to the end (I am not totally contracting what I reply  
to, that is all about covering all cases).

It may be any Buffer : it is variable, not a constant (the buffer is not  
the better example here, but let go on with here)

Practical view : this buffer may (let imagine) be used consecutively for  
different things, and the analysis may say this is OK to have one buffer  
because of use always comes after the other (and the buffer may be big so  
we have to declare only one, to reach some specifications).

Abstract view : a Buffer_Type defines something. Right ? Now, what is a  
variable declared of type Buffer ? It is what is defined by the type  
Buffer, right ? (if this would be something different, then language or  
the compiler is really broken). Then, if you've named Buffer as Buffer,  
how will you name a variable of the same type without more (see later for  
the more) ? Use a different name ? But if you use a different name,  
doesn't that mean the name of the type could be different or is ambiguous  
? The good word to say what the type is, will be the same to say what the  
variable is (but there is one difference, see later).

First part of my agreement : I fully agree with the point “what is special  
with that buffer ?”. Ex. you have two buffers, one for input, one for  
output : “Input_Buffer : Buffer; Output_Buffer : Buffer;”. That sounds  
natural, OK. But some other times this is not feasible, because the entity  
declared of the type is simply fully generic (you can give it a tricky  
name, which will not sound natural, as the natural word is the one of the  
type, or else, the type does not hold the good name or holds an ambiguous  
name).

About the more : think about an inventory machine in a library, it has a  
method named Run_Inventory, and inside this, a loop and a book variable.  
This book has nothing special at all, as it is by definition, to hold any  
what book you may imagine. This variable, here, is, simply what the Book  
type, is. So your question is indeed very good : what is different ? The  
answer : one is a type, the other is an instance  So how do you name it ?  
With a name which expose the difference
  Either Book_Instance and Book or
else Book and Book_Type or even, if you like it Book_Instance and  
Book_Type. Book_Instance is the place for different name : A_Book,  
Any_Book, Current_Book, etc. What ever, you will add to the instance name,  
something which you reject for the type name (paradox ?).


Sometime it is possible to get ride of _Type, but sometime it is not  
always, and this is not predictable, and your design should cover the  
“always” otherwise it will hold a bug. If you decide it for the user, this  
is not good : premature decision. You cannot assert the user will never  
define very generic instance of that type (and there are common, see later  
[*]).

Now, how much or what is the average occurrence of generic use instance ?  
I would say, many (near to third or half, my experience says), at least  
with function and procedure parameters (especially when there is a single  
parameter of the same type, which is a common case), iterators, persistent  
storage, streams, intermediate expression, temporary variables, an so on;  
or else, simply the role is indicated by the outer scope and this is  
redundancy to add a mark for it to the variable. About the latter, what  
about “Inventored_Book” or “Current_Book” in the loop of the above  
inventory machine ? Is it worth to repeat it every where ? Does it really  
offers something to the reader ? (think of it in context)


You idea is good, but it does not cover all the range, and you are right,  
sometime, but not all the time. If an entity does not have enough thing  
special, you are not to invent it just to name it (this would not be to  
design anymore), you are to name it for what it is (that is design). And  
what if this has nothing special or else what is special with it, is  
already expressed in the direct outer context or what it is attached to  
(case of records or subprogram parameters) ?


Another alternative for people who do not like _Type and feels hurt with  
it, could be to serve each type declaration, with a name to be used for  
instances-without special identity.

    type Book is private; -- Typical instance name: Set_Of_Written_Sheets.
                          -- Sorry, I do not know a good English synonym.
                          -- Note: some API do something a bit similar, when
                          -- they define common abbreviations for variables
                          -- of a type.


[*] When I read sources which does not use the “_Type” convention (or  
something similar, there are multiple choice, and either on the variable  
or on the type), including some part of the ARM, there are tricky names  
(which are disturbing for the reader) or hard game to find synonyms, which  
makes me wonder what the next will be (funny game) or if the type was  
really given the good name. That is funny in literature to play with  
multiple synonymous of a word or close-meaning words; but although I enjoy  
the concept of Literate Programming, computer language source is not  
literature (the expression Literate Programming is only partly related to  
literature), it is not the same kind of entertainment. When a name does  
not sound natural and like to play the “guess what next” game with you,  
this is not good for readability (the reader has some other priorities).


P.S. For reader of this news-group: this only applies to languages which  
are case insensitive, as as-you know, there is a common convention in  
language with case sensitivity, to use a capital letter (like natural  
language when it needs to distinguish proper names) which plays the same  
role as _Type here.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.