Re: Types, packages & objects : the good old naming conventions question (without religious ware)

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

Stephen Leake schrieb:

> Nonsense; it is _precisely_ what I want; a list of abstract objects.
> 
> You can't avoid the naming problem by changing the context!

But there should be better ways to resolve the naming problem
when changing context.  Better than being unspecific, that is:
it sure is possible, if redundant, to give a hint to the
context.

> Here are the similar definitions from
> Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start
> arguing that is a bad abstraction.

No, though it is perhaps notworthy that IIRC the container
type's name used to be "Container" in every package in some
earlier editions.  (I couldn't resist saying some more on
names and abstract programming in another reply.)


> Note that it uses _Type for Element!

I think Element_Type was not chosen in order to take sides with
the _Type convention.


> How is that better than this:
> 
> package Ada.Containers.Indefinite_Doubly_Linked_Lists is
> 
>    type List_Type is tagged private;
> 
>    generic
>       with function "<" (Left, Right : Element_Type) return Boolean is <>;
>    package Generic_Sorting is
> 
>       function Is_Sorted (List : List_Type) return Boolean;
>    end Generic_Sorting;

There are fewer occurrences of "List" that need disambiguation.
But I'll happily leave it to that empirical study of the effects
of naming conventions whether other solutions work better or
worse.

>> (Rules here: Bits _of_ something, sensor _of_ something,
>> these are examples following Tom Moran's comment, if I'm
>> not mistaken. Names Sensor and Bits are really quite abstract.
>> I would force them to be used for abstract types' names, at best.)
> 
> Yes, if you have a specific context and a specific meaning, then you
> should use a specific name. The corollary is that if you have a
> generic context, you should use a generic name.

But is the generic context really unspecifiable, i.e.,
do we have to become vague in our naming?
We could state, using names, or adorned names, or ...,
that something is useful in many specific cases.
This fact is a distinguishing feature.



> [List]
> 
> Who said this was a linked list?

Any programmer with a Lisp background will assume List is :-)

If what matters is the set of operations needed,
then is it not possible to specify a frame of reference
for this particular meaning of "List"?


> [SAL] "list" tends to imply some access order, meaning there is at
> least First, Next, Is_Done. Containers don't have those functions.

This is where conventions can cause problems.

package Ada.Containers.Hashed_Sets is
  ...
  function First (Container : Set) return Cursor;

SAL and Ada.Containers differ in their approaches to the same problem,
both using the same names connected to incompatible set of operations...



>> generic
>>     type Less_Equal is new Ordering with private;
>> procedure Sort (Container : in out Linked_List);
>>
>> Is anything lost here?  
> 
> Yes! You have lost the fact that this is a generic procedure that
> doesn't care about the internal structure of the list.

OK. But then, personally, I would have though that (or the
abstract linking you have mentioned) would distinguish a List.

> You have also
> lost the ability to specify the Order at run-time.

Why?  Can't I instantiate with any Ordering type from
any block that happens to be visited at run time?


> And "less_equal" implies a mathematical sort. All I really need for a
> sort that produces a linear order is "goes_before".

"Goes_Before" a better name, then.  Though it corresponds to "Less"
only, not "Less_Equal", doesn't it?  (I'm desparately looking
for how the [= relation is pronounced.  Not_After?)

>> I think Dylan made an attempt, at least if one is satified with "car"
>> being in a different namespace than "<car>".
> 
> Clearly it's a different name; it's a different lexeme. That's
> the same as the _Type convention. 

I think this is significant:  Many of us care about lexemes
much less than digital computers in that we rather correct
oddities like spelling errors or <framings> in letter patterns.


>> I'd still not pick essentially the same name for object Car
>> and type Car though. Even if Ada had one namespace for types
>> and one for other entities.  An object is never the same
>> as a type, therefore it should be possible to distinguish
>> the difference using words.
> 
> Yes! Car is distinguished from Car_Type, but List is not distinguished
> from Container. Thank you for agreeing with me :).

OK, to me, Car_Type is only minimally different from Car,
and not sufficiently.  In particular, the difference carries
no meaning in either the objects domain, or in the comain
of the value sets of types.
(I guess we both would not write procedure Speed_Subprogram (...))


> Actually, I disagree with this statement; overloading types and
> objects is fine, since the language does make the distinction clear
> from context. In Dylan, I would use "car" and "<car>".
> 
> It sounds like you don't like overloading in the first place. How
> about this: 
> 
>     adding integers is never the same as adding float; it should be
>     possible to distinguish the difference using words

OCaml does, though with a bit of black dirt only.

> So you don't like "+" (Left, Right : in Integer) and "+" (Left, Right
> : in Float)?
> 
> If you do like operator overloading, how is that different from
> object/type overloading?

I don't like conventional operators in Ada programs,
and more so in C programs:
They create a huge set of problems when people think
they know what they are doing when writing "+".