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

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 11/3/10 9:38 PM, Warren wrote:
> Georg Bauhaus expounded in
> news:4cd19583$0$6977$9b4e6d93@newsspool4.arcor-online.net:
>
>> 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.
>
> Ok, so the type is a Storage_Buffer. So is the instance
> of the type.

Actually, the type is not a Storage_Buffer.  The type has no
"is a" relation to Storage_Buffer, the type defines what
instances of Storage_Buffers are going to be like. Each object
"is a"  Storage_Buffer. A type is not.   OK, that's nitpicking.

A child born is of type Child.  A son is of type Son.  Sometimes
fathers address the Child: "Son, ...!"  But the son still
has a name.  If you have another son, maybe younger, you
know how to tell them apart.  And if there are two or more
around, "Son, ...!" may not work as intended.So they've got
names, to resolve the issue.  Suppose there
is just one.  Should computer programming therefore dismiss
assigning single sons a name and just name them "Son"?

In natural language, "Son, ..." may be a special form
of address.  Something out of the ordinary.  This meaning
is not covered by the *type* Son.  Maybe our overloading
of meanings of Son lets us think we might use the same naming
scheme in formal programming, if *we* know there is one
particular Son object around and we write the statements
addressing it.  Doesn't seem like a good idea to me to carry
this over to formal programming.

The Romans just counted sons, Primus, ..., Quintus, say.
Every son "is a" Son, but none of them were without identity
and none was *named* son!   Just *called*, at times, and
in special situations where ambiguity is resolved by human
means, not by a compiler.

Therefore, then, do we do ourselves a favor if we use  this
style of anonymity by duplicating the type name for objects?
For example, "Tu quoque, fili?" can be clarified in programming
by just injecting the name Brute, for an object of type Son.
As in

package body Caesar

  procedure Last_Words is
  begin
     Say ("To quoque, Brute, fili mi?")
  end Last_Words;

end Caesar;

I guess that for insiders, the phrase might not be catchy enough.
Too long. But for a more formal analysis, the specific object is nicely
spelled out (Brute), and the relation is clear, too (mi): Brutus,
that's the son's name, is Caesar's son (fili mi), not just someone's
son (fili) as a computer could infer, absent a possessive pronoun.

Suppose the string had just been "To quoque, fili", without Brute and
without mi.  The program's author sure had known better.

He had known the name but decided not to give it.
Why not?


> Storage_Buffer : Storage_Buffer;
>
> doesn't get us any closer to solving the problem. ;-)
>
> Sometimes the number of instances is one -- matching the
> type.  In cases like these you are still left with the
> task of making them different-- merely for the purpose
> making them different.

I still think that not having a object name based on the object's
role, say,  shows that you have not yet clearly named the purpose
of this object in the program.   Sometimes that's enough.
I think, however, that quick and dirty anonymity characterizes
programs that need but a limited amount of engineering.