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

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

[Hibou57 (Yannick Duchêne)]

Hi,

Still reading a new chapter of the Ada 95 Quality and Style Guide, the
“ CHAPTER 3: Readability ” ( http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1
) has inspired me to ask for more about the subject.

The one which troubles me the most, is the most common convention
about type names, without a suffix. This one is very common, and so
much common that even the Ada standard packages set relies on it.
There are Boolean, not Boolean_Type, Integer, not Integer_Type, as
this Chapter 3 recalls.

A long time ago, a time when I was using Pascal, I wondered about this
topic (without any guide at the time), and tried something which was
the same as this seemingly most commonly used Ada convention, but I
ended into troubles with most of type names, which were conflicting
with the most obvious name of objects. Not all the time, but oftenly.

I do not mean I'm surprised this convention is working fine with the
Ada standard packages set, I know there is probably a reason which
explains why it works in this one case : types defined by the Ada
standard, all have names which express somethings very abstract. As an
example, Integer would unlikely be the name of any variable, because
it is too much abstract to be the name of the concrete instance of
anything. But with at a greater level of specialization, things turns
to show another face : types tends to have names which are more
subject to conflict with object / instance names, because as they are
more specialized, they have much more concrete meaning and semantic,
and there come the conflicts potential.

A basic type may be Integer, as a basic type Integer is a very
abstract thing, and as a very abstract thing, this will not conflict
with the name of a very concrete thing.

What is realized with basic types, is likely to be less basic, and as
it is less and less basic, this will be more and more close to the
name which may be given to the less abstract thing known : the
concrete instance.

Indeed, the word Map, is more likely to be the name of an object
instance as well as the name of a type, than Integer is. The same with
things like Document, Account, Vegetable, etc.

I remember the headache it was to imagine instance's names which was
not conflicting with type names (in that order of occurrence, because
types are always defined and designed before instance).

That's why I'm wondering if in the Ada area, people really use or not,
the convention without a suffix. I can guess it works find with Ada
standard stuff, for the reasons introduced just before, but it is more
difficult to me to imagine how this same convention can practicably
works as much fine with larger projects dealing with much more
concrete types.

There is on the other hand, this other convention, which came from
Pascal I suppose : the one which ends types name with the suffix _Type
(there is also the Borland convention which starts a type name with a
prefixed capital T, but as _Type is more wordy and separates words
with an underscore, it better match expectations in the Ada area than
the Borland convention may ever do).

This convention which consist of the use of the suffix _Type, is
referred to in this chapter, so it means it is a well known
convention, while in the mean time, I had never see it recommended in
any Ada style guide. To be short : seems to be known, but seems to be
fully unused in real projects (except perhaps in students works).

It's easy to accept large scale projects as being a proof of the
relevance of a naming convention. That's why this may be useful to
some peoples, if someone who has ever worked on a “ Real ” project (a
project which had a real life time), could talk about it, with replies
to these two questions : 1) how the name collision troubles between
highly specialized type names and instance names can be resolved with
a convention which does not rely on a dedicated suffix or prefix for
type names ? 2) Is the convention with a suffix really not used (as it
appears to not be) ?

Experienced feed-backs welcome ;)


Now another stuff, still about naming convention :

This Chapter 3 also introduced two main naming convention schemes, one
which seems to comes from who-know-who, and one which comes from JP
Rosen.

At first sight, I was a bit surprised by the one suggested by JP
Rosen. In short, I silently though “ all main type defined in a
package has the name Instance, and its class wide view has the name
Class... this is the least expressive things one may imagine, I don't
want this ”. But later, I figured out that in practice, this may be
indeed relevant because this is not the name of the type which
identify what it is, but rather its package name. First, a type is
nothing alone, it makes sense associated with a set of associated
method only, and the set of the type + its methods, is identified by
the package, so the package makes sense, more than the type does, so
yes, the package name is the first thing which requires a meaningful
name, not the type. Secondly (not less important), for people who like
to not Use, the type name is just a component of a package, and thus
its name can be used as the name of something which always appears
with its context, the package, just like what it is with the component
of a record. One should not choose the name of a record component the
same way he/she choose the name of a standalone instance, like a
variable. So finally, what first seems to me a convention to obviously
avoid, appeared to me, to be the best one. Note : to go further, JP
Rosen explains in a paper, how this convention is also fine for people
who Use : http://pagespro-orange.fr/adalog/publicat/naming9x.pdf ( see
at the end of “ 3 A convenient naming convention ” ).

There are just some points, like the one that I feel _Mixin better
express what it stands for than _Facet does ( I referring to the Ada
95 Q&SG here ), because _Mixin clearly express that it has to be mixed
to be used, while _Facet erroneously seems to stands for something
which is already there in existence. Also that I think its useful to
use the Abstract_ prefix for package defining abstract type, because I
was always adding an comment like “ this package defines an abstract
type ”, and this is true this is better expressed in the package name
than in an heading comment. I do not really agree with the choice of
Instance suggested by JP Rosen, which, as the name say, mean an
instance, what a type will never be.

But in the overall strategy, names choices kept apart, the Rosen way
seems good, and would just need to be completed with a few more
standard prefix and suffix.

That's just what I'm looking for : other documents about naming
convention, to know existing sets of prefix and suffix identifying
some aspects of packages (like Abstract_ and _Mixin). I've just found
this Ada Q&SG, but need more, and I prefer to use already established
conventions than create one which only be known of me.

Any suggestions welcome if coming from things in use in real projects
(suggestions about how to name package may be also, because I really
have troubles with this... too much long names occurs here at home).



(hum... guess peoples who will answer this — if there are ever — will
have to be very pleased to do so, ... cause I was long with this one).

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

[Dmitry A. Kazakov]

On Thu, 29 Oct 2009 10:11:56 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote:

> I do not mean I'm surprised this convention is working fine with the
> Ada standard packages set, I know there is probably a reason which
> explains why it works in this one case : types defined by the Ada
> standard, all have names which express somethings very abstract. As an
> example, Integer would unlikely be the name of any variable, because
> it is too much abstract to be the name of the concrete instance of
> anything. But with at a greater level of specialization, things turns
> to show another face : types tends to have names which are more
> subject to conflict with object / instance names, because as they are
> more specialized, they have much more concrete meaning and semantic,
> and there come the conflicts potential.

A great observation.

> Indeed, the word Map, is more likely to be the name of an object
> instance as well as the name of a type, than Integer is.

No, Map is abstract enough, no less than Integer. Look at the operations +,
-, *, / the Ada designers too had a trouble with names. They use Left,
Right as the names, not very convincing. Mathematicians keep on using x, y.

As for Map I used Container to name an instance of in its operations.

> That's why I'm wondering if in the Ada area, people really use or not,
> the convention without a suffix. I can guess it works find with Ada
> standard stuff, for the reasons introduced just before, but it is more
> difficult to me to imagine how this same convention can practicably
> works as much fine with larger projects dealing with much more
> concrete types.

It is difficult. Sometimes I give up and add "_Type", but I always feel
myself guilty if I do.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Britt Snodgrass]

A short reply to a long post:

I share your perspective.  I work on "real" projects and our
convention is to always use a "_Type" or " _Range" suffix on type and
subtype names.  I've also tried "_T" and but didn't like it as much.
It is still tricky to name type hierarchies (e.g., arrays of records).
I have occasionally used long suffixes like "_Record_Type" and
"_Record_Array_Type" but that can quickly get out of hand.

- Britt

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

[Georg Bauhaus]

Hibou57 (Yannick Duch�ne) schrieb:

> There is on the other hand, this other convention, which came from
> Pascal I suppose : the one which ends types name with the suffix _Type

If you can't find a name for an object, ask more questions
about it, its use, its relations, the programmer, its purpose,
his purpose, etc:
What is the role of the object?  Does the role lead to a name?
It might not, at first.  For example, the role
can be given as "just any object" of the type.  I would not be
comfortable with such an answer (though, for practical reasons,
I live with it):
The person who says "just any object" should be able to give
a reason why "just any object" is sufficient.  The reason,
and in particular stating the reason using words, increases the
likelyhood of finding a name expressing the reason.
Or the reaons leads to other ideas which, again, lead to a
name.


Naming conventions always make me think of features
that a language does not offer.  I don't think this is
the case with types and objects in Ada.

> It's easy to accept large scale projects as being a proof of the
> relevance of a naming convention.

Microsoft's software is certainly of a larger scale.
They suggested "Hungarian" notation at some point.
Do they use, or suggest to use, "Hungarian" notation with .NET?
I don't think so.  So much for relevance of large scale.
If naming conventions help with missing features,
does Ada lack features that .NET offers
and that need to be compensated by a _Type suffix?

Mass alone, or big projects, are, IMHO, not a sign
of relevance without further corroboration.
Big projects can fail, too, but to define success is
more likely a political issue in large projects than
in small projects.  Whenever success or failure involve
"politics" and incomplete information, it is more difficult
to attribute success or failure to reasons given or
to reasons hidden.  (Let alone the effects of disiring
cognitve consonance...)

Here is a prossible study that is much less political,
yet will never happen, I think:
A group of programmers, equally skillful, separates itself
into two groups, along a dividing line between personal coding
preferences:
The first group consist of programmers who are fond of
the _Type suffix, the second group consists of programmers
who avoid these mechanical names.  Both groups set out
to solve the same problem.

- Which group finishes first?
- Which group can change things faster than the other?
- Again?
- Which group's members are better at explaining
  the software?

Etc.

The study needs to be augmented by performing it again,
trying conventional alternate research setups, to make
data valid and reliable.  (Switching the group preference,
using a third group that does not know about
conventions, ...)

Does such a study exist?  If not, why not?
The last question is the important one, I think:
It costs money.  It is personal (about style) and
personal information is kept personal, not studied.
Its findings might reflect on pride and fashion,
most important aspects of all craftsmanship, a no-no
when there is a risk of a negative result.
A study might have as a result: Do NOT wear the ties
you like so much (_Type or else wonderful names).
If the result of the study must be assumed to be regulation
of programming style, prohibiting personal preferences
for members of one group but not the other,
then is there any programmer who would want the study
to happen?

Is there a manager who understands the issue?

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

[Niklas Holsti]

Hibou57 (Yannick Duch�ne) wrote:

> Still reading a new chapter of the Ada 95 Quality and Style Guide, the
> � CHAPTER 3: Readability � ( http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1
> ) has inspired me to ask for more about the subject.
> 
> The one which troubles me the most, is the most common convention
> about type names, without a suffix.
> 
> That's why I'm wondering if in the Ada area, people really use or not,
> the convention without a suffix.
 > ...
 > 2) Is the convention with a suffix really not used (as it
 > appears to not be) ?

For over a decade and several middling-large projects I've been using 
the "_T" suffix for all types, the only exceptions being that I use the 
suffix "_Ref" when I want to make it evident that the type is an access 
type, and (for some reason that I don't really understand) I prefer the 
suffix "_Type" for generic formal types.

Thus a typical declaration looks like Map : Map_T and a generic 
instantiation has associations like Element_Type => Frommit_Ref, 
Container_Type => Map_T.

The suffix method removes one intellectual burden, is systematic, and 
"_T" is short enough to be quickly typed and quickly read, so I'm happy 
with this system.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Jeffrey R. Carter]

Hibou57 (Yannick Duch�ne) wrote:
> 
> The one which troubles me the most, is the most common convention
> about type names, without a suffix. This one is very common, and so
> much common that even the Ada standard packages set relies on it.
> There are Boolean, not Boolean_Type, Integer, not Integer_Type, as
> this Chapter 3 recalls.

A quick Google groups search will find more than one long thread on this 
subject. Basically, people fall into 2 groups on this subject: those who agree 
with me, and those who are wrong :)

Some people are wrong the other way: They don't allow type suffices, but instead 
use object and parameter prefixes: A_, An_, The_.

FWIW, I am currently on a large, multi-person project which outlaws _Type, _T, 
and the prefixes, and the resulting code is quite readable.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

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

[tmoran]

> - Which group finishes first?
> - Which group can change things faster than the other?
> - Again?
> - Which group's members are better at explaining
>   the software?
>
> Etc.

Etc.
  - Give the software to another group that has never seen it and
    see how quickly, and how correctly, they understand and can
    make changes to it.
  - People differ.  You may not find that one style is consistently
    better for all programmers.  Can you find a way to tell which
    style is better for a particular programmer to write or for
    a particular programmer to read, and use that information in
    making your programming and maintenance assignments?

>  Does such a study exist?  If not, why not?
Perhaps such a study has been conducted, either formally or
informally, and it did not appear there was a large, clear,
benefit to one style or the other, so the decision was made,
either explicitly or implicitly, to leave the choice up to
the particular programmer or team.

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

[Robert A Duff]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

>...  For example, the role
> can be given as "just any object" of the type.  I would not be
> comfortable with such an answer...

In some cases, "just any object" is the right answer.
No need for discomfort.
For example, parameters of general-purpose procedures.

    function To_Upper(X: String) return String;
    --  Convert X to upper case.

There's nothing interesting to say about X, except that
it's a String.  Just any String.  Trying to come up with
a meaningful name for X will just generate noise.

In the standard package Ada.Characters.Handling, it's
called Item, which is no more meaningful than X.

In the GNAT front end, there are huge numbers of parameters
declared as:

    N : Node_Id

- Bob

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

[Georg Bauhaus]

On 10/30/09 1:01 AM, Robert A Duff wrote:

> In some cases, "just any object" is the right answer.
> No need for discomfort.
> For example, parameters of general-purpose procedures.
>
>      function To_Upper(X: String) return String;
>      --  Convert X to upper case.
>
> There's nothing interesting to say about X, except that
> it's a String.  Just any String.  Trying to come up with
> a meaningful name for X will just generate noise.

I agree, and would add the following restriction:
A case excluded from the rule "nothing interesting
to say about <name> except that it's a <type>" is when
there are many of those <name>s.  I have seen too many
transcriptions of formulas (and also instances where
math writing habits have been carried over to computer
porograms):  The domain knowledge compressed into single
letters in the writings of the domain specialist (which
are written and read in domain context), is just copied
into a program.  But the programming context is different!
So the text should be different, too, to reflect the
different context.

But authors complain that languages like Pascal,
Ada, or Scheme < R6RS, don't let them have names
"p" and "P" denote different objects in the same
declarative part...

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

[Hibou57 (Yannick Duchêne)]

On 29 oct, 19:11, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> If you can't find a name for an object, ask more questions
> about it, its use, its relations, the programmer, its purpose,
> his purpose, etc:
> What is the role of the object?  Does the role lead to a name?
> It might not, at first.  For example, the role
> can be given as "just any object" of the type.  I would not be
> comfortable with such an answer (though, for practical reasons,
> I live with it):
> The person who says "just any object" should be able to give
> a reason why "just any object" is sufficient.  The reason,
> and in particular stating the reason using words, increases the
> likelyhood of finding a name expressing the reason.
> Or the reaons leads to other ideas which, again, lead to a
> name.

(just about this sole point, the remaining later)

An example trap (to me at least) : what about a type which would seems
obviously named Size and a parameter which seems obviously named
Size ? X would surely not be OK, neither Item.

An idea may be to get a more or less close synonymous (like Count...
not very good) for the parameter for which one may naturally be
tempted to name Size. But this seems (and is) a work-around, and if
the word “ work-around ” really legitimately applies on that
situation, this means there is a trouble (not natural, at least). Why
the work around will probably applied on the parameter ? Because the
parameter comes later when the type definition is already introduced
(in the worst case, it may be tempting to change the type name). This
latter detail makes us to come to another aspect of the trouble :
choosing a practicable type name, may requires an amount of prediction
over what instance names may be.

Note : Triggering this, I'm not attempting to advocate for the _Type
or other _Xxx suffix convention, as I honestly find that using a
simple noun as a type name, is smart and elegant in many ways. I'm
just attempting to evaluate both cases in a formal and long life
prediction way.

I'm short with this reply, but I will be back to reply to other
interesting stuff written back here by peoples.

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

[Jeffrey R. Carter]

Hibou57 (Yannick Duch�ne) wrote:
> 
> An example trap (to me at least) : what about a type which would seems
> obviously named Size and a parameter which seems obviously named
> Size ? X would surely not be OK, neither Item.

If Size is the best name for the parameter, and assuming this a numeric value, 
then I'd call the type Size_Value.

> An idea may be to get a more or less close synonymous (like Count...
> not very good) for the parameter for which one may naturally be
> tempted to name Size. But this seems (and is) a work-around, and if
> the word � work-around � really legitimately applies on that
> situation, this means there is a trouble (not natural, at least). Why
> the work around will probably applied on the parameter ? Because the
> parameter comes later when the type definition is already introduced
> (in the worst case, it may be tempting to change the type name). This
> latter detail makes us to come to another aspect of the trouble :
> choosing a practicable type name, may requires an amount of prediction
> over what instance names may be.

I think that you shouldn't be writing anything until you've decided on the type 
and its operations, including their parameters.

This isn't trouble. A type is usually only part of what you're creating, and 
it's important to think about the whole thing before committing any part of it 
to code. This is especially true for the visible part of a pkg spec.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

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

[Hibou57 (Yannick Duchêne)]

On 30 oct, 06:08, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> I think that you shouldn't be writing anything until you've decided on the type
> and its operations, including their parameters.
>
> This isn't trouble. A type is usually only part of what you're creating, and
> it's important to think about the whole thing before committing any part of it
> to code. This is especially true for the visible part of a pkg spec.

That's a good note (in my mind, I was thinking about any context, but
its clear that the one you've pointed is particularly important and
should be guiding).

So let's go further the standalone concept of naming convention, and
add a seed of method, which may say “ name a type and its instance
names in primitives, all together (and the remaining should be OK) ”

:)

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

[Niklas Holsti]

Jeffrey R. Carter wrote:
> Hibou57 (Yannick Duch�ne) wrote:
>>
>> The one which troubles me the most, is the most common convention
>> about type names, without a suffix. This one is very common, and so
>> much common that even the Ada standard packages set relies on it.
>> There are Boolean, not Boolean_Type, Integer, not Integer_Type, as
>> this Chapter 3 recalls.
> 
> A quick Google groups search will find more than one long thread on this 
> subject. Basically, people fall into 2 groups on this subject: those who 
> agree with me, and those who are wrong :)
> 
> Some people are wrong the other way: They don't allow type suffices, but 
> instead use object and parameter prefixes: A_, An_, The_.
> 
> FWIW, I am currently on a large, multi-person project which outlaws 
> _Type, _T, and the prefixes, and the resulting code is quite readable.

Interesting. How does you project solve the type-naming problem? Do you 
have some positive rules for naming types and objects, or only those 
negative prohibitions against suffixes and prefixes?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[tmoran]

> An example trap (to me at least) : what about a type which would seems
> obviously named Size and a parameter which seems obviously named
> Size ? X would surely not be OK, neither Item.

  There is no Size by itself - it's the Size of something. So a function
to calculate the price of a pumpkin, based on its size, would be
  function Price(Pumpkin_Size : Size) return Dollars;
You can shorten by using a pronoun and depending on the context to
disambiguate:
  function Price(Its_Size : Size) return Dollars;
That's as far as you can go if Size is the type name.  If you used
something else, eg Size_Type or Size_T or Sizes, then you could shorten
the parameter name all the way to Size.  Since you probably write variable
names much more often in the code than the type name, it makes sense to
try to shorten them, at the expense of slightly longer type names.
IMHO

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

[dhenry]

I'm working on a "real" project and the convention we have chosen is
to use suffixes _Type, _Array_Type and _Access:

type Foo_Type is private;
type Foo_Access is access all Foo_Type;
type Foo_Array_Type is array (Positive range <>) of Foo_Type;

We use simple rules, so that _Access can be either used for an
"access", and "access all" or an access on a 'Class. If we need both
class-wide access and simple access, we can use _Class_Access but it's
not hard-written in our coding standard rules. This may not be
rigorous, but we're fine with it because it's simple (when we decided
about our coding standards, we didn't want to produce dozens of pages
of rules).

However there are some drawbacks, like how to name a variable which
should be "message type" (an integer identifying the kind of a
message). We can't use Message_Type, so we use Message_Typ (which is
of type Message_Typ_Type). That's not pretty at all.

I have a question for people not using any suffix like _Type or _T or
whatever: how do you name your access types? Do you allow here to use
a suffix?

Yours,
David.

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

[Hibou57 (Yannick Duchêne)]

On 30 oct, 10:24, dhenry <tfc.d...@gmail.com> wrote:
> I'm working on a "real" project and the convention we have chosen is
> to use suffixes _Type, _Array_Type and _Access:
>
> type Foo_Type is private;
> type Foo_Access is access all Foo_Type;
> type Foo_Array_Type is array (Positive range <>) of Foo_Type;
>
> We use simple rules, so that _Access can be either used for an
> "access", and "access all" or an access on a 'Class. If we need both
> class-wide access and simple access, we can use _Class_Access but it's
> not hard-written in our coding standard rules. This may not be
> rigorous, but we're fine with it because it's simple (when we decided
> about our coding standards, we didn't want to produce dozens of pages
> of rules).

Interesting,

I was coming there as the wind, but I wanted to reply to your message
immediately, to say that except in one point, your convention is the
exact same as the one I'm using until now (decision still pending
about it). The only difference is with Array_Type, which would simply
be _Type for me, because I would choose a name for the type, which,
may be not really express it's an array, and rather express it is a
kind of set of something (something which contains multiple items),
thus I would have probably choose a plural there, something as simple
as Strings_Type or alternatively and depending on usage, something
like String_List_Type or String_Set_Type (I'm just not tied to
_Array_).


> However there are some drawbacks, like how to name a variable which
> should be "message type" (an integer identifying the kind of a
> message). We can't use Message_Type, so we use Message_Typ (which is
> of type Message_Typ_Type). That's not pretty at all.
I use a special case for this kind of stuff : simply _Kind, as an
example, Message_Kind, which means the same as Message_Type_Type. As
Message_Type_Type is more disturbing than helpful to understand, I
would use Message_Kind. I use AdaControl to check for naming
convention, and I've got a rule to check that all enumeration type
name ends with the suffix _Kind. While TBH, this turns into trouble
with derived type from character, but this is the only one case which
is not perfect there, as I name derived type from character with
_Type, and not _Kind.

This convention to use _Kind instead of _Type_Type, should be useful
to any one concerned with stuff like opcodes, low level hardware
interfacing and the like ;) (while not only).

That said, I'm trying to learn about alternatives and weight each of
these, just to make a choice because I knew about choices and not
because I did not knew about any others (and want the best choice, not
the only one at first time available to me).

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

[Stephen Leake]

"Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr> writes:

> Hi,
>
> Still reading a new chapter of the Ada 95 Quality and Style Guide, the
> “ CHAPTER 3: Readability ” ( http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1
> ) has inspired me to ask for more about the subject.
>
> The one which troubles me the most, is the most common convention
> about type names, without a suffix. This one is very common, and so
> much common that even the Ada standard packages set relies on it.

Not entirely; Ada.Text_IO.File_Type, and others, follow the _Type
convention (which is the better convention :).

> A long time ago, a time when I was using Pascal, I wondered about this
> topic (without any guide at the time), and tried something which was
> the same as this seemingly most commonly used Ada convention, but I
> ended into troubles with most of type names, which were conflicting
> with the most obvious name of objects. Not all the time, but oftenly.

Right, this is the reason for using _Type on type names.

> I do not mean I'm surprised this convention is working fine with the
> Ada standard packages set, I know there is probably a reason which
> explains why it works in this one case : 

It works for the standard because people are very flexible, and can
work around quirks like this while convincing themselves it's better.

It would take less effort to use a package if all types followed the
_Type convention. Then more people would have more time to write more
Ada code, and we'd take over the world.

> A basic type may be Integer, as a basic type Integer is a very
> abstract thing, and as a very abstract thing, this will not conflict
> with the name of a very concrete thing.

Parameters are very abstract things as well; that's where most
object/type name conflicts occur:

    procedure Sort (List : in out List)

which occurance of "List" is less abstract? Better to not have to
think about it.

> That's why I'm wondering if in the Ada area, people really use or not,
> the convention without a suffix. I can guess it works find with Ada
> standard stuff, for the reasons introduced just before, but it is more
> difficult to me to imagine how this same convention can practicably
> works as much fine with larger projects dealing with much more
> concrete types.

Right. Just use _Type; life will be better. And the more code people
write with _Type, the sooner everyone will be converted to the One
True Way.

> This convention which consist of the use of the suffix _Type, is
> referred to in this chapter, so it means it is a well known
> convention, while in the mean time, I had never see it recommended in
> any Ada style guide. To be short : seems to be known, but seems to be
> fully unused in real projects (except perhaps in students works).

I use it in my projects:

http://www.stephe-leake.org/

http://gds.gsfc.nasa.gov/

> It's easy to accept large scale projects as being a proof of the
> relevance of a naming convention. 

No, just proof of the flexibility, stubborness, and differences in
opinion among people.

> 1) how the name collision troubles between highly specialized type
> names and instance names can be resolved with a convention which
> does not rely on a dedicated suffix or prefix for type names ? 

It can't. Objects and types share the same name space. There are only
two choices:

a) use a convention to split this into two name spaces (trailing _Type
is the most common convention; others are possible).

b) spend extra effort on each object coming up with a name that is
different than the type.

> 2) Is the convention with a suffix really not used (as it appears to
> not be) ?

No.

> Now another stuff, still about naming convention :

Better to start another thread for a different topic.

> This Chapter 3 also introduced two main naming convention schemes, one
> which seems to comes from who-know-who, and one which comes from JP
> Rosen.
>
> At first sight, I was a bit surprised by the one suggested by JP
> Rosen. In short, I silently though “ all main type defined in a
> package has the name Instance, and its class wide view has the name
> Class... this is the least expressive things one may imagine, I don't
> want this ”. But later, I figured out that in practice, this may be
> indeed relevant because this is not the name of the type which
> identify what it is, but rather its package name. 

That depends on whether you use "use" clauses:

with Bar;
with Baz;
procecure Foo is

    A : Bar.Instance;
    B : Baz.Instance;
...
end Foo;

or:

with Bar; use Bar;
with Baz; use Baz;
procedure Foo is

    A : Some_Bar_Type;
    B : Some_Baz_Type;

...

end Foo;

This is more a matter of style and personal taste than the _Type
issue.

Even in this case, Instance_Type would be better; then the subprograms
in Bar could use Instance as a parameter name.

-- 
-- Stephe

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

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Hibou57 (Yannick Duch�ne) schrieb:
>
>> There is on the other hand, this other convention, which came from
>> Pascal I suppose : the one which ends types name with the suffix _Type
>
> If you can't find a name for an object, ask more questions
> about it, its use, its relations, the programmer, its purpose,
> his purpose, etc:
> What is the role of the object?  Does the role lead to a name?

Why should I have to waste time on this?

answer those questions for this:

    procedure Sort (List : in out List; Order : in Order_Type);

> Naming conventions always make me think of features
> that a language does not offer.  I don't think this is
> the case with types and objects in Ada.

It _is_ the case for Ada! The feature "separate name spaces for types
and objects" is not offered by Ada. I'm not aware of a language that
does offer this feature, but it certainly is within the realm of
possibility.

-- 
-- Stephe

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

[Stephen Leake]

Britt Snodgrass <britt.snodgrass@gmail.com> writes:

> A short reply to a long post:
>
> I share your perspective.  I work on "real" projects and our
> convention is to always use a "_Type" or " _Range" suffix on type and
> subtype names.  I've also tried "_T" and but didn't like it as much.

Interesting. I also use _Type, but I always have. I think in general,
abbreviations are discouraged in Ada. I know I generally tolerate
longer names in Ada than in C++.

> It is still tricky to name type hierarchies (e.g., arrays of
> records). I have occasionally used long suffixes like "_Record_Type"
> and "_Record_Array_Type" but that can quickly get out of hand.

That is not because of _Type; compound types are always harder to name.

-- 
-- Stephe

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

[Hibou57 (Yannick Duchêne)]

On 30 oct, 11:52, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Why should I have to waste time on this?
I first though I would not influance any one here whith personal
decisions, but I tempted to disobey to my self, and confess I agree :
I'm quite sure I will keep going on using the convention I'm using.

> It _is_ the case for Ada! The feature "separate name spaces for types
> and objects" is not offered by Ada. I'm not aware of a language that
> does offer this feature, but it certainly is within the realm of
> possibility.
>
> --
> -- Stephe
Yes, there is one : it is called ... Eiffel ;)

You know... the ones who sometime come here at night where they see
some lights around here

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

[Georg Bauhaus]

Stephen Leake schrieb:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> Hibou57 (Yannick Duch�ne) schrieb:
>>
>>> There is on the other hand, this other convention, which came from
>>> Pascal I suppose : the one which ends types name with the suffix _Type
>> If you can't find a name for an object, ask more questions
>> about it, its use, its relations, the programmer, its purpose,
>> his purpose, etc:
>> What is the role of the object?  Does the role lead to a name?
> 
> Why should I have to waste time on this?

Because the time "wasted" on thinking about the roles (properties,
relations, ...) of named entities in your programs, and
then not being silent about your results, instead naming the
entities suitably according to your results, and explicitly
saying what you mean, is

(a) spent anyway, though to different extents, on this very
    issue

(b) is not wasted: first because of (a), second because
    if you think about the entities, and name them properly,
    the positive effect is the same as in all human
    communication:

P1 (in the kitchen): "P2? Mind giving me that?"
P2 (in the living room): "What?"
P1: "That thing over there."
P2: "Where?"
P1 (approaches):  "There." (P2 moves) "No, there."
"No, not that, that!"
...

Alternatively, P1 could with trained effort name things
and their relations:

P1 (in the kitchen): "P2? Mind giving me the crystal vase
standing on the sideboard next to the door?"


Obviously, the second example shows a naming convention
that is less sloppy, less abstract (than "that", "there")
and more specific.
I am sure P2 will know what to do, because he can
understand and interpret the meaning of well
chosen names, and they are well connected.
P2 of the first example is in a different situation
which is characterized by a waste of energy,
cause by a lack of specific names and good connections.


> answer those questions for this:
> 
>     procedure Sort (List : in out List; Order : in Order_Type);

I had immediately come up with some ideas on seeing this
example (without the Order parameter!) in your other post.

"List" is a darn bad abstraction name here!  (For illustration
we could similarly praise a ubuquituous type name such as "Bits"
when what is meant is "Temperature_Sensor.Connector_Bits", say.)

(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.)

List in your original example without the Order parameter was
almost certainly a Partial_Order even without an Order parameter
in sight (since in the modified example you have given in this
posting there is an Order parameter).  Next, the List is a partial
order of element of some type.  Only in a reusable subprogram
their type, if irrelevant, adds but noise (as per Bob Duff's rule).
Since there is now an explicit Order parameter, I will assume
that the List is really just a set of items without an order,
and the name "List" only alludes to the mode of accessing
the elements (sequentially, linked in some unknown way).

If I understand "Sort" meant as a generically useful procedure,
then, as Dmitry has said, the first argument can be named "Container",
since it contains the elements of the list (the type of Container).
Without some hint to an order, a type name "List" says enough about
the structure of the actual parameter (Container).

"Order" is somewhat unspecific.  The "List" context helps when
guessing that Order refers to a mathematical ordering relation.
Its not a call to order, say, in a program controlling the
president's electronic bell in some parliament.

Inside the procedure, you might want to emphasize the links of
the elements to be sorted.
One way to achieve this is to rename the parameter "Container"
to "Linked_Elements" (I'd think it is somewhat pompous, though.
The implementer will know how to deal with the name Container.
The reader of Sort's body will know what Container is, too.
Because the type name, such as "Linked_List" gives the necessary
information.)

generic
    type Less_Equal is new Ordering with private;
procedure Sort (Container : in out Linked_List);

Is anything lost here?  This is a reusable Sort, then.
The declaration still leaves open whether we can safely assume
that Sort will produce the result in ascending order.


>> Naming conventions always make me think of features
>> that a language does not offer.  I don't think this is
>> the case with types and objects in Ada.
> 
> It _is_ the case for Ada! The feature "separate name spaces for types
> and objects" is not offered by Ada. I'm not aware of a language that
> does offer this feature, but it certainly is within the realm of
> possibility.

I think Dylan made an attempt, at least if one is satified with "car"
being in a different namespace than "<car>".

define method sell(car :: <car>, new-owner :: <string>) => ();
  if (credit-check(new-owner))
    car.owner := new-owner;
  else
    error("Bad credit!");
  end;
end;

(from http://www.opendylan.org/gdref/tutorial/ch03.html)

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.

Here, I'd think about the role of the parameter "car".
There is more information available, the car object has
a role.  Maybe this is better:

define method sell(vehicle-on-sale :: <car>, ...

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

[Jeffrey R. Carter]

Niklas Holsti wrote:
> 
> Interesting. How does you project solve the type-naming problem? Do you 
> have some positive rules for naming types and objects, or only those 
> negative prohibitions against suffixes and prefixes?

We don't have any rules (that must be obeyed), but we do have guidelines. I have 
listed them before.

First, save the best name for parameters. This means the type name is always 2nd 
best.

Then, there are some common naming conventions that apply in many situations. 
Numeric types often represent values, and <Best_Name>_Value is often a 
meaningful way to form the type name.

Enumeration types are often names or IDs, so _Name or _ID.

Arrays are often lists or sets, so _List or _Set.

Record types often provide the necessary information about something, so _Info. 
In some cases, _Group is good.

Private types let you manipulate something without knowing what's in it, so 
_Handle often seems appropriate.

_Handle also often seems good for access types.

But we always want the (2nd) best name; a private type used as an ID would have 
_ID, not _Handle. A type that acts as a key (in a map, for example) might be _Key.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

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

[Jeffrey R. Carter]

dhenry wrote:
> 
> However there are some drawbacks, like how to name a variable which
> should be "message type" (an integer identifying the kind of a
> message). We can't use Message_Type, so we use Message_Typ (which is
> of type Message_Typ_Type). That's not pretty at all.

I like Kind here: Message_Kind for the type and Kind for parameters and objects 
of the type.

> I have a question for people not using any suffix like _Type or _T or
> whatever: how do you name your access types? Do you allow here to use
> a suffix?

The objection is not to suffices; it's to suffices that add no value, which is 
true of _T[ype]. I personally like _Ptr for access types; on my current project 
the guideline is to use _Handle if there isn't a better name.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

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

[Jeffrey R. Carter]

Stephen Leake wrote:
> 
> Why should I have to waste time on this?

The time is not wasted. I've said before that _T[ype] is an excuse for not doing 
necessary thinking. Good names document the code and make it easier to 
understand; mindlessly adding _T[ype] to a general concept name for the type 
name and mindlessly using the general concept name for all parameters and 
objects of the type doesn't. If you don't spend the time and effort involved to 
think about and use good names, then everyone who reads the resulting code has 
to do the equivalent thinking to understand the code.

When you see

Append (List => List, Element => Element);

you don't really know what's being appended to what. Compare that to

Append (Onto => Widget_List, Item => Next_Widget);

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

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

[Hibou57 (Yannick Duchêne)]

On 30 oct, 19:57, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> When you see
>
> Append (List => List, Element => Element);
>
> you don't really know what's being appended to what. Compare that to
>
> Append (Onto => Widget_List, Item => Next_Widget);

So in some way, the difference between the not-suffixed convention and
the suffixed convention, has something similar to the difference
between typed and non-typed (or loosely typed) language ?

You want to mean it may be more long, sometime a bit difficult, but
finally better express things, just like strong typed language takes
sometime more long to setup a design, but are finally give clearer and
more explicit architectures.

But is it an universal feature or is it because it is Ada which does
not allow object name and type name to be the same (you may reply that
if Ada does not allow this, this to enforce different names)

I ask questions, but right now try to give my first feeling about it :
typing express the logic of a domain, and if typing is not well
designed, this means the domain is not well modeled. But naming deals
with natural language, whose concern is not the same as formal
languages. So natural languages may not provide all the vocabulary
required to express all specific nuances which come with formal
languages.

After all (and now I'm back to the opposite way after the previous
suggestion), isn't the _Type suffix, something similar to the ending
"s" meaning the plural ? If natural languages were close to formal
languages, there may be a suffix expressing that a thing is an
instance abstraction (a type) or even a class, just like natural
languages gave us the plural mark.

Two ways, with both good arguments, but this may help to better
understand (linguistic and things around may be good guests here).

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

[Hibou57 (Yannick Duchêne)]

A quick add-on, before I forget to write it back here - comments
welcome on the assertion :

A program language terms use the dictionary of natural language.
The natural language has some construct like predicates, adjectives,
verbs (transitive and intransitives ones), an nouns.

some has one to one match with the concepts used in a program text :
predicates and adjectives, verbs (of both forms).

Remain nouns : they may match either object of types, just because the
natural language does not make this distinction. Indeed, in every day
life, we are not talking using type and class concepts (neither our
ancestors does).

Human being understanding of things, which is reflected in the nature
of the language it use (the Human being), because it creates the
language to serve to purpose of transmitting its minds, prefer to use
stereotypes : it take a typical example, which is a *real* instance,
and defines other instances after that typical real instance.

Thus, the word « cat », which may either refer to Douda, my pet cat,
or to all Cat being (if I can say it this way).

So, it may be seen as un non-formal proof that the vocabulary and word
derivation construct from natural languages, does not provide anything
to make a clear distinction between an instance and the abstraction of
any-instance-of, simply because any instance, may be subject to become
a typical representation of an abstraction as soon as it is notices
that it has finally some property which makes it different from others
and that these properties are shared by some other. Ex. my Pet Cat,
she like to beat just to play. There are others which do the same. At
first sight, she is well represented by the typical representation of
a cat, which is some cat (any one), but later, when you know her, you
use this reference to her in another way.

So, in the natural way of Human being understanding process, there is
no distinction at all, between an object and a type or a class,
because an object may become a type or a class at any time.

Finally, the natural language the Human being has created fulfill the
needs of this process, providing a set of words which can serve this
purpose, that, words which means things which may be either object or
types, without this distinction being made.

Here comes the clash between object name and type name. Perhaps this
is not a matter of weither or not some one did not choose the good
word from the natural language, and more a matter of that the natural
language does not provide good words for that purpose : a word which
may match the expression of what a type is, may be found, but with two
things important to note : this word will never express it is a type
(for the reason expressed before) and this word will *necessarily* be
the word which should be used as well to name an object (still for the
reason introduced before).

At this point, there is three possible way to do things (if you think
about others, just add your own and tell about) :

1) Created fully new words dedicated to type, not coming from the
natural language, as the natural language does not provide any.
2) Formally split - in a developers wide standardized way - the whole
set of words from the natural language in two separate and non-mixable
set : one set for restricted to objects name, one set restricted for
type names.
3) Add a derivation (which is a known construct of the natural
language), to mark some property on some words, just like the already
given example of plural does with the “s”. This may be done it self in
three possible way : create a mark for types, meaning “ I'm a type
” (object will be the ones without this mark), or create a mark for
objects, meaning “ I'm an object ” (types will be the ones without
this mark), or create a mark for both type and object, meaning “ I'm a
type ” for the first one and “ I'm an object ” for the second one.

Comments on these methods (if you think about others, add you own as
well).

About 1) : this would not be practicable... the set of words from the
natural language taken long to be created, and Human being capacity to
learn such a things is not unlimited (this would be nice for a machine
to create and use such a create-from-the-ground-up language, but we
are Human beings, not machines).

About 2) : such a standard would take long, long, long, with infinite
elections before being stable. And further more, we may discover that
one objet-type (as with natural language its always the two things at
the time) may only have a single word to refer to, and no synonym at
all. Then, even providing we may be able to standardize such a split,
we may end up with some object without word (or type without word), as
we will have to decide if we assign this unique word to either the
type names set or object names set. Then and even if it would be less
work to learn it (less than with the proposition #1), this would still
be a lot of work for every one to learn it, ... and be sure there will
be confusion, because we will have two set of words, whose words from
one set will be synonyms of the words from the other set (synonym in
the natural language way, but not in the program text way).

About 3) : there are in turn three way to do it.

About 3.1 (a mark for types) : a lot of people already know it, so no
need to explain.
About 3.2 (a mark for object) : it seems it has been in use in some
old methodologies (I do not know names, sorry), I used it my self in
some old Pascal programs.
About 3.3 (a mark for both) : just combine de two previous

Some along fact about 3) :
- We spend more time to read than we spend time to write.
- We write more object names than we write type names (indeed, there
more instance than there instance abstraction, except in libraries).

This may be a suggestion to have shorter names for object (quicker to
read and to write) than for types, thus this may be a suggestion to
drop 3.3 and 3.2, leaving just 3.1

Remains a thing which after all this formalizations, will remain a
matter of taste : the choice of the mark on the type (suffix, prefix,
casing - not for ada - and anything else, things which already in use
in some conventions).

Is this mark very important to be standardized ? Perhaps not, as soon
as it clearly appears to stand for types, it is clearly distinct
(should not be erroneously seen as the part of a word - the Ada
underscore may help there) and easy to write and read (just avoid
exotic characters or marks, even if some may be tempted in some
mathematic of linguistic dedicated character sets).

Time for comments now


Note : if a language makes more use of types than objects, objects
should have the mark instead of types, that's obvious, while better
said explicitly.

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

[Hibou57 (Yannick Duchêne)]

On 31 oct, 06:30, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr>
wrote:
> [...] simply because any instance, may be subject to become
> a typical representation of an abstraction as soon as it is notices
> that it has finally some property which makes it different from others
This make me think that the natural language is better at analysis
than it is at expressing static architecture based on formalism after
analysis.

this is not surprising, from thousands years, we are more busy at
trying to understand things, come back on a previous understanding and
reworking it (this is why it is useful to be able to have a thing
which is both things). The natural language is after all perhaps
better at always-moving things rather than at well-elaborated-and-
expected-stable things.

Hey boys and girls... you know what ? I think the natural language is
an untyped loosy structured language 8-| We should rework it in
whooole and send a long spicy disclaimer to its author.

Splitting the object and type name spaces? (Was: Types, packages & objects : the good old naming conventions question (without religious ware))

[Jacob Sparre Andersen]

Stephen Leake wrote:

> Objects and types share the same name space.

How much trouble would it be to split the object name space from the
type name space in Ada?

What kinds of dangers would it introduce?

Greetings,

Jacob
-- 
Black Hole: Where the universe made a Divide by Zero.

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

[Jacob Sparre Andersen]

tmoran@acm.org wrote:

> Since you probably write variable names much more often in the code
> than the type name, it makes sense to try to shorten them, at the
> expense of slightly longer type names.

Now I simply have to quote Preben Randhol:

  "Saving keystrokes is the job of the text editor, not the
   programming language."

Personally I find types the most important construct in Ada.  This
means that I generally try to give the "best" names to types.

Naming of objects and types would be easier, if we could use two
separate name spaces. But maybe our code would become harder to read?

Greetings,

Jacob
-- 
Warning: Dates in calendars are closer than they appear.

Re: Splitting the object and type name spaces? (Was: Types, packages & objects : the good old naming conventions question (without religious ware))

[Hibou57 (Yannick Duchêne)]

On 31 oct, 07:27, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> How much trouble would it be to split the object name space from the
> type name space in Ada?
>
> What kinds of dangers would it introduce?
Not dander, as you may guess, but troubles or inconsistencies against
long history. Although it is possible to switch from a unique name-
space to two name-space (and not the opposite), this would be
considering the language alone and forgetting about its usage :
readers and program text. For readers reading program text, this would
make all program texts written so far, very singular against the
language rules. You will have all these text using one name-space
only, while the language would allow two.

This would seems to be another language.

(this would be OK only if it would have been the same from the
beginning)

> Black Hole: Where the universe made a Divide by Zero.
Do you think it raises an exception ?

Re: Splitting the object and type name spaces? (Was: Types, packages & objects : the good old naming conventions question (without religious ware))

[Hibou57 (Yannick Duchêne)]

(forgotten)

and the syntax will turns into ambiguous constructs, because there are
place where this would not be possible to know if an identifier is to
be a type or an object/function.

B := A (Index) -- View conversion or array or function ?

To make the distinction between array and function is easy (the array
may be seen as a kind of function) : both cannot have the same name,
so it is what has this name. If A is declared as an array, this is an
array, if A is declared as a function, this is a function.

But if A can be a function/array name and a type name in the same
time, there is a trouble.

This may be the danger you are looking for : the whole language syntax
will need to be reworked (forget about all backward compatibility).

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

[Dmitry A. Kazakov]

On Fri, 30 Oct 2009 22:30:43 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote:

> A quick add-on, before I forget to write it back here - comments
> welcome on the assertion :
> 
> A program language terms use the dictionary of natural language.
> The natural language has some construct like predicates, adjectives,
> verbs (transitive and intransitives ones), an nouns.
> 
> some has one to one match with the concepts used in a program text :
> predicates and adjectives, verbs (of both forms).

Verb ~ [primitive] operation
Predicate/adjective ~ constraint (e.g. "in"), indexing

> Remain nouns : they may match either object of types, just because the
> natural language does not make this distinction. Indeed, in every day
> life, we are not talking using type and class concepts (neither our
> ancestors does).

No, I think this is wrong. In natural languages there is a distinction
between class and instance. In English (I am not native speaker) it is the
+ uncountable/plural. Other languages have different means.

> Thus, the word � cat �, which may either refer to Douda, my pet cat,
> or to all Cat being (if I can say it this way).

"the cats"

In the natural languages the difference is always blurred because classes
can be objects, e.g. form super classes.

So in the programming languages. The types have operations of they own
though rudimentary in Ada (e.g. T'Class, T'Image). You cannot separate the
name spaces of them and the objects. (The same it true for subprograms.)

Note that generic programming is programming in terms of sets of types. In
Ada it is represented by generics and class-wides. Generic programming is
considered extremely important paradigm. Here you again come to the case
where a type is no more a "proper noun", but just an instance of something
more unique.

Note also that at the formal level type and object are strictly different.
Other programming languages (like C++, Java) have failed here by not
distinguishing T and T'Class. Nevertheless for the programmer, conceptually
cat is-a cat, and he wants to write programs as-if x of T, were of T'Class.
You can never solve this psychological problem. The language shall
differentiate object and type, type and class, class and meta class and so
on ad infinitum. But the programmer will flow up and down this hierarchy of
abstractions choosing his objects and types at each level and names for
them.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Splitting the object and type name spaces? (Was: Types, packages & objects : the good old naming conventions question (without religious ware))

[Dmitry A. Kazakov]

On Sat, 31 Oct 2009 07:27:08 +0100, Jacob Sparre Andersen wrote:

> Stephen Leake wrote:
> 
>> Objects and types share the same name space.
> 
> How much trouble would it be to split the object name space from the
> type name space in Ada?
> 
> What kinds of dangers would it introduce?

Some additional ambiguities, e.g.

   X'First  -- X is a type or an array?

Conceptually the language has the common space for everything named. If we
wanted to separate types, we should also do the packages, the labels, the
operations.

The latter is the most difficult part, because subprograms need to be
passed as parameters, and they are equivalent to literals and objects when
parameterless.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Hibou57 (Yannick Duchêne)]

On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> "the cats"
This is a class, not a type
So let's call classes The_Xxxs (with an ending S)
But what about types ? (and instances of a type)

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

[Dmitry A. Kazakov]

On Sat, 31 Oct 2009 04:30:38 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote:

> On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> "the cats"
> This is a class, not a type
> So let's call classes The_Xxxs (with an ending S)
> But what about types ? (and instances of a type)

Class is a set of types. Type is a set of values. When the cat is an
object, the cats is its type. Mammals is the set of types that contain the
type cats. The corresponding type can be the mammals, i.e. flatten mammals
class.

In Ada there is no notation for the class. T'Class is a type, the closure
of the class rooted in T, i.e. all values of the members of types derived
from T.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Stephen Leake schrieb:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>> 
>>> Hibou57 (Yannick Duch�ne) schrieb:
>>>
>>>> There is on the other hand, this other convention, which came from
>>>> Pascal I suppose : the one which ends types name with the suffix _Type
>>> If you can't find a name for an object, ask more questions
>>> about it, its use, its relations, the programmer, its purpose,
>>> his purpose, etc:
>>> What is the role of the object?  Does the role lead to a name?
>> 
>> Why should I have to waste time on this?
>
> Because the time "wasted" on thinking about the roles (properties,
> relations, ...) of named entities in your programs, and
> then not being silent about your results, instead naming the
> entities suitably according to your results, and explicitly
> saying what you mean, is
>
> (a) spent anyway, though to different extents, on this very
>     issue

Yes, but that applies to both the object name and the type name;
making them _different_ requires _extra_ effort.

> P1 (in the kitchen): "P2? Mind giving me that?"
> P2 (in the living room): "What?"
> P1: "That thing over there."
> P2: "Where?"
> P1 (approaches):  "There." (P2 moves) "No, there."
> "No, not that, that!"

This is _not_ a good analogy; "that" is not a subprogram parameter in
the kitchen!

>>     procedure Sort (List : in out List; Order : in Order_Type);
>
> "List" is a darn bad abstraction name here!  

Nonsense; it is _precisely_ what I want; a list of abstract objects.

You can't avoid the naming problem by changing 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.

package Ada.Containers.Indefinite_Doubly_Linked_Lists is

   type List is tagged private;

   generic
      with function "<" (Left, Right : Element_Type) return Boolean is <>;
   package Generic_Sorting is

      function Is_Sorted (Container : List) return Boolean;
   end Generic_Sorting;
end Ada.Containers.Indefinite_Doubly_Linked_Lists;

Note that it uses _Type for Element!

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;

end Ada.Containers.Indefinite_Doubly_Linked_Lists;

> (For illustration we could similarly praise a ubuquituous type name
> such as "Bits" when what is meant is
> "Temperature_Sensor.Connector_Bits", say.)

But nothing specific is "meant" here; it is a generic, in the truest
English meaning of that word.

> (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.

> List in your original example without the Order parameter was
> almost certainly a Partial_Order even without an Order parameter
> in sight (since in the modified example you have given in this
> posting there is an Order parameter).  Next, the List is a partial
> order of element of some type.  Only in a reusable subprogram
> their type, if irrelevant, adds but noise (as per Bob Duff's rule).
> Since there is now an explicit Order parameter, I will assume
> that the List is really just a set of items without an order,
> and the name "List" only alludes to the mode of accessing
> the elements (sequentially, linked in some unknown way).

Ok.

> If I understand "Sort" meant as a generically useful procedure,
> then, as Dmitry has said, the first argument can be named "Container",
> since it contains the elements of the list (the type of Container).

Obviously; that's the approach Ada.Containers takes. It can also be
named "list", since that means exactly the same thing. Or the type can
be named "container", for the same reason.

There is the large risk that one person will decide on :

    procedure Sort (Container : in out List);

and another will choose:

    procedure Sort (List : in out Container);    

Now somebody has to decide, and one has to go back and make lots of
trivial (and therefore error-prone) edits.

I suppose one person could choose List_Type and the other
Container_Type, but at least that's a smaller fix to unify them.

> Without some hint to an order, a type name "List" says enough about
> the structure of the actual parameter (Container).
>
> "Order" is somewhat unspecific.  

Yes, deliberately.

> The "List" context helps when guessing that Order refers to a
> mathematical ordering relation. Its not a call to order, say, in a
> program controlling the president's electronic bell in some
> parliament.

Yes, obviously; this is a programming language context, not "the real
world".

> Inside the procedure, you might want to emphasize the links of
> the elements to be sorted.

Who said this was a linked list? Ada.Containers.Doubly_Linked_Lists
is, my original example doesn't care. I guess you could be refering to
abstract links.

See http://www.stephe-leake.org/ada/sal.html
sal-gen-alg-find_linear-sorted.ads for an abstract sort procedure. It
uses Container and Container_Type; "list" does have the connotation of
"linked list", "container" is slightly more abstract. But I often use
the name "list" for an implementation that happens to be an unbounded
array; "list" tends to imply some access order, meaning there is at
least First, Next, Is_Done. Containers don't have those functions.

> One way to achieve this is to rename the parameter "Container"
> to "Linked_Elements" (I'd think it is somewhat pompous, though.
> The implementer will know how to deal with the name Container.
> The reader of Sort's body will know what Container is, too.
> Because the type name, such as "Linked_List" gives the necessary
> information.)

That would be wrong; you are adding/imposing a structure that is not
necessarily there.

> 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. You have also
lost the ability to specify the Order 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". We tend to map all
things into numbers, so "less_equal" makes sense. But it's really
better to say "A goes before B", instead of "A is less than B".

"Ordering" could also imply a partial order, as for military rank; all
generals first, then all lieutenants, seargents, etc. Less_Equal can
mean that, but "Military_Rank" would be clearer.

>>> Naming conventions always make me think of features
>>> that a language does not offer.  I don't think this is
>>> the case with types and objects in Ada.
>> 
>> It _is_ the case for Ada! The feature "separate name spaces for types
>> and objects" is not offered by Ada. I'm not aware of a language that
>> does offer this feature, but it certainly is within the realm of
>> possibility.
>
> 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'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 :).

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

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?

-- 
-- Stephe

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

[Stephen Leake]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Stephen Leake wrote:
>>
>> Why should I have to waste time on this?
>
> The time is not wasted. I've said before that _T[ype] is an excuse for
> not doing necessary thinking. Good names document the code and make it
> easier to understand; mindlessly adding _T[ype] to a general concept
> name for the type name and mindlessly using the general concept name
> for all parameters and objects of the type doesn't. If you don't spend
> the time and effort involved to think about and use good names, then
> everyone who reads the resulting code has to do the equivalent
> thinking to understand the code.

Yes, you need to pick good names. Having picked good names, why waste
_more_ time picking _different_ names for type vs object?

> When you see
>
> Append (List => List, Element => Element);
>
> you don't really know what's being appended to what. 

In a purely generic context, like in the body of
Ada.Containers.Indefinite_Doubply_Linked_LIsts, that is precisely what
you should know.

What's wrong with that?

Ah, perhaps you mean "am I appending Element to List, or List to
Element"? I don't think that's a reasonable objection; List is clearly
the container, here, given the English meanings of the words.

> Compare that to
>
> Append (Onto => Widget_List, Item => Next_Widget);

In the body of a container of widgets, yes, this is appropriate.

I don't see any difference between "Item" and "Element";
Ada.Containers uses "Element", SAL uses "Item".

"Onto" almost makes sense, because "Append this onto that" is proper
English. Note that the order in the code is wrong, though! 

But in a package containing several operations on an abstract type,
it's better to use the same name for the abstract type parameter in
all operations. Otherwise the user has to keep checking what that name
is:

Op_1 (onto => list, element => object_1);
Op_2 (from => list, element => object_2);
Op_3 (container => list, element => object_3);

It's much easier if it's always "list => list".

-- 
-- Stephe

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

[Stephen Leake]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Hibou57 (Yannick Duchêne) wrote:
>>
>> An example trap (to me at least) : what about a type which would seems
>> obviously named Size and a parameter which seems obviously named
>> Size ? X would surely not be OK, neither Item.
>
> If Size is the best name for the parameter, and assuming this a
> numeric value, then I'd call the type Size_Value.

Why not follow the typical convention, and call the type Size_Type?
The type name occurs in fewer places, so it's less noise to modify the
type.

>> An idea may be to get a more or less close synonymous (like Count...
>> not very good) for the parameter for which one may naturally be
>> tempted to name Size. But this seems (and is) a work-around, and if
>> the word “ work-around ” really legitimately applies on that
>> situation, this means there is a trouble (not natural, at least). Why
>> the work around will probably applied on the parameter ? Because the
>> parameter comes later when the type definition is already introduced
>> (in the worst case, it may be tempting to change the type name). This
>> latter detail makes us to come to another aspect of the trouble :
>> choosing a practicable type name, may requires an amount of prediction
>> over what instance names may be.
>
> I think that you shouldn't be writing anything until you've decided on
> the type and its operations, including their parameters.

That's not possible, even in principle. You need use cases in order to
design a good type and operations.

-- 
-- Stephe

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

[Stephen Leake]

tmoran@acm.org writes:

>> An example trap (to me at least) : what about a type which would seems
>> obviously named Size and a parameter which seems obviously named
>> Size ? X would surely not be OK, neither Item.
>
>   There is no Size by itself - it's the Size of something. So a function
> to calculate the price of a pumpkin, based on its size, would be
>   function Price(Pumpkin_Size : Size) return Dollars;

You need 100,000 of these functions in a typical large grocery store.
Ada doesn't support this:

   function Price(Pumpkin_Size : Size) return Dollars;
   function Price(Milk_Size : Size) return Dollars;
   function Price(Granny_Smith_Apple_Size : Size) return Dollars;

Clearly this will be

   function Price (Item : Item_Type; Size : Size_Type) return Dollars;

The context associates Size with Item; no need to add more noise.

>   function Price(Its_Size : Size) return Dollars;
> That's as far as you can go if Size is the type name. If you used
> something else, eg Size_Type or Size_T or Sizes, then you could
> shorten the parameter name all the way to Size. Since you probably
> write variable names much more often in the code than the type name,
> it makes sense to try to shorten them, at the expense of slightly
> longer type names. IMHO

Exactly; that's why we use Size_Type.

-- 
-- Stephe

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

[Stephen Leake]

dhenry <tfc.duke@gmail.com> writes:

> I'm working on a "real" project and the convention we have chosen is
> to use suffixes _Type, _Array_Type and _Access:
>
> type Foo_Type is private;
> type Foo_Access is access all Foo_Type;

I use Foo_Access_Type for this.

> type Foo_Array_Type is array (Positive range <>) of Foo_Type;

I use Positive_Array_Foo_Type for this last one.

> We use simple rules, so that _Access can be either used for an
> "access", and "access all" or an access on a 'Class. If we need both
> class-wide access and simple access, we can use _Class_Access but it's
> not hard-written in our coding standard rules. This may not be
> rigorous, but we're fine with it because it's simple (when we decided
> about our coding standards, we didn't want to produce dozens of pages
> of rules).
>
> However there are some drawbacks, like how to name a variable which
> should be "message type" (an integer identifying the kind of a
> message). We can't use Message_Type, so we use Message_Typ (which is
> of type Message_Typ_Type). That's not pretty at all.

Yes, this case is a problem. I just use Message_Type_Type, and live
with it.

Apparantly in Dylan, that would be Message_Type for the object, and
<Message_Type> for the type. I like that better.

-- 
-- Stephe

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

[Stephen Leake]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> dhenry wrote:
>>
>> I have a question for people not using any suffix like _Type or _T or
>> whatever: how do you name your access types? Do you allow here to use
>> a suffix?
>
> The objection is not to suffices; it's to suffices that add no value,
> which is true of _T[ype]. I personally like _Ptr for access types; on
> my current project the guideline is to use _Handle if there isn't a
> better name.

We happen to think _Type adds a lot of value; it saves effort during
writing and reading code. I agree it doesn't add any intrisic meaning
to the word, but that's not the only kind of value that's important.

-- 
-- Stephe

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

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Britt Snodgrass <britt.snodgrass@gmail.com> writes:
>
>> A short reply to a long post:
>>
>> I share your perspective.  I work on "real" projects and our
>> convention is to always use a "_Type" or " _Range" suffix on type and
>> subtype names.  I've also tried "_T" and but didn't like it as much.
>
> Interesting. I also use _Type, but I always have. I think in general,
> abbreviations are discouraged in Ada. I know I generally tolerate
> longer names in Ada than in C++.

Another point; _T could easily be part of an object name (short for
time, or top, or a math subscript of some sort). _Type is clearer.

-- 
-- Stephe

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

[Hibou57 (Yannick Duchêne)]

On 31 oct, 12:47, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 31 Oct 2009 04:30:38 -0700 (PDT), Hibou57 (Yannick Duchêne) wrote:
> > On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> "the cats"
> > This is a class, not a type
> > So let's call classes The_Xxxs (with an ending S)
> > But what about types ? (and instances of a type)
>
> Class is a set of types. Type is a set of values. When the cat is an
> object, the cats is its type. Mammals is the set of types that contain the
> type cats. The corresponding type can be the mammals, i.e. flatten mammals
> class.
You are right, this is not a class.
But the type may rather be seen as an abstraction of each individual
instance (or as a representation of all the possible instances, thus
the set, but not as a set of instances). The type, provide the way to
create an instance, it may be used to create a set of value, but it is
not a set of value (I know you use type right, I'm just trying to make
terms clear).

So let say now your « The Cats » is a type, and finally there is
something which mark it, so this goes in the way of a mark to state a
name is used a a type. “ The ” and the plural, may be seen as
equivalent to the “ _Type ”

The only disclaimer I would add, is that I would not name a type using
a plural. This may seems natural at the type definition, but this will
be less natural at object instantiations (unless the type is a
containers, and the containers is named after the concrete type of
items it contains).

> In Ada there is no notation for the class. T'Class is a type, the closure
> of the class rooted in T, i.e. all values of the members of types derived
> from T.
This do the job, isn't it ? And this is true that a type — which may
be, at least potentially — the subject of any number of derivations,
at least potentially stands for a class, even it is not actually
derived. So there is no trouble to get the class rooted at a type from
a type attribute. There is no need for an explicit declaration of a
class, because the class associated to a tagged type, always exist,
that's the concept, and does not need any declaration (the subtype is
there, if a declaration is needed or wished).


Thanks for having notice (I mean, thanks for the correction)

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

[Hibou57 (Yannick Duchêne)]

On 31 oct, 13:21, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> > type Foo_Type is private;
> > type Foo_Access is access all Foo_Type;
>
> I use Foo_Access_Type for this.

What's your reason to use Foo_Access_Type instead of Foo_Access ?
Is that because of objects named Foo_Access ?

(just wanted to know)

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

[Dmitry A. Kazakov]

On Sat, 31 Oct 2009 05:38:32 -0700 (PDT), Hibou57 (Yannick Duchêne) wrote:

> On 31 oct, 12:47, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sat, 31 Oct 2009 04:30:38 -0700 (PDT), Hibou57 (Yannick Duchêne) wrote:
>>> On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> "the cats"
>>> This is a class, not a type
>>> So let's call classes The_Xxxs (with an ending S)
>>> But what about types ? (and instances of a type)
>>
>> Class is a set of types. Type is a set of values. When the cat is an
>> object, the cats is its type. Mammals is the set of types that contain the
>> type cats. The corresponding type can be the mammals, i.e. flatten mammals
>> class.

> You are right, this is not a class.
> But the type may rather be seen as an abstraction of each individual
> instance (or as a representation of all the possible instances, thus
> the set, but not as a set of instances). The type, provide the way to
> create an instance, it may be used to create a set of value, but it is
> not a set of value (I know you use type right, I'm just trying to make
> terms clear).

Well, the set of all values of a type is equivalent to the type itself. It
would make little sense to distinguish them. That is formally. Practically
there is an aspect of constructiveness. We cannot enumerate all integers,
so we name them as Integer in order refer the set of, without constructing
it in the body. Any set of values is a type but it is incomputable to
decide of which type. In other words since structural equivalence does not
work we need type names. And even if the type T is "new Integer", indeed an
integer, we do not recognize that, and treat T and Integer distinct types.
That is another reason why we are short in type names.

> So let say now your « The Cats » is a type, and finally there is
> something which mark it, so this goes in the way of a mark to state a
> name is used a a type. “ The ” and the plural, may be seen as
> equivalent to the “ _Type ”

This is the instance-to-set way, but there is reverse approach:
set-to-instance. E.g. "of x", the possessive case "x's", the article "a x".
Natural languages are damn flexible.

Some people like:

   procedure Skin (Cat : A_Cat);

others do

   procedure Skin (A_Cat : Cat);

(:-))

I don't like either. Sometimes I do:

   procedure Skin (Victim : Cat);

Many do

   procedure Skin (Object : Cat);

Some natural languages apply cases to indicate objects:

   procedure Skin (Objet : Cat; Tool : Knife; Customer : Butcher);

(accusative, instrumental, dative cases). Interestingly that cases
represent some kind of types (roles) of objects.

>> In Ada there is no notation for the class. T'Class is a type, the closure
>> of the class rooted in T, i.e. all values of the members of types derived
>> from T.

> This do the job, isn't it ? And this is true that a type — which may
> be, at least potentially — the subject of any number of derivations,
> at least potentially stands for a class, even it is not actually
> derived. So there is no trouble to get the class rooted at a type from
> a type attribute. There is no need for an explicit declaration of a
> class, because the class associated to a tagged type, always exist,
> that's the concept, and does not need any declaration (the subtype is
> there, if a declaration is needed or wished).

No, it is rather because T in T'Class is decidable. But it is not
necessarily always so. Already with generics people run straight into
troubles passing T'Class for a plain formal type and wondering why no
dispatch happen. Again the question is how and if "member of" is
computable/obvious. Once types might become a more first-class citizens, or
the structure of classes more complicated T'Class might cease to work well.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Stephen Leake]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:

> Remain nouns : they may match either object of types, just because the
> natural language does not make this distinction. Indeed, in every day
> life, we are not talking using type and class concepts (neither our
> ancestors does).

This is an interesting point.

There are some cases of English nouns that are by definition groups; a
gaggle of geese, a pride of lions. But there is no general convention
for this.

I don't know enough other languages to say whether this is a universal
truth about human languages.

> Is this mark very important to be standardized ? 

Maybe for Ada 83; it is too late now.

-- 
-- Stephe

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

[Stephen Leake]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:

> On 31 oct, 13:21, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> > type Foo_Type is private;
>> > type Foo_Access is access all Foo_Type;
>>
>> I use Foo_Access_Type for this.
>
> What's your reason to use Foo_Access_Type instead of Foo_Access ?

Just so the convention "all types end in _Type" is universal. That
helps when building tools that generate code, like Auto_Text_IO.

I'm also more rigid than a lot of people when it comes to rules.

> Is that because of objects named Foo_Access ?

I rarely do this; I use "Foo" for either a Foo_type object or a
Foo_Access_Type object, unless I need both in the same scope. Even
then, I usually use _Ptr, not _Access.

But it is a valid reason for Foo_Access_Type.

-- 
-- Stephe

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

[Stephen Leake]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> tmoran@acm.org wrote:
>
>> Since you probably write variable names much more often in the code
>> than the type name, it makes sense to try to shorten them, at the
>> expense of slightly longer type names.
>
> Now I simply have to quote Preben Randhol:
>
>   "Saving keystrokes is the job of the text editor, not the
>    programming language."

Yes, but reading is also important. The _Type suffix is essentially
noise when reading; it's only there for the compiler, not the human.
So you want to read it as few times as possible, as well as write it
as few times as possible.

-- 
-- Stephe

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

[Peter C. Chapin]

Stephen Leake <stephen_leake@stephe-leake.org> wrote in 
news:u4ope4pqa.fsf@stephe-leake.org:

> Yes, but reading is also important. The _Type suffix is essentially
> noise when reading; it's only there for the compiler, not the human.
> So you want to read it as few times as possible, as well as write it
> as few times as possible.

This seems backwards to me. I could use a type name such as X72efY9 for all 
the compiler cares. The _Type suffix is most definitely for the human. It 
says, "Hey! This is the name of a type so keep that in mind when looking at 
this code."

In the past I used _Type as a suffix for all of my types. However, there 
are times when that doesn't seem to fit. After all the standard types don't 
(usually) use a _Type suffix (Character, Integer, Positive, Vector, etc). 
Lately I've become a lot less strict about using _Type suffixes in my code.

Peter

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

[Hibou57 (Yannick Duchêne)]

Suggested reading : http://p.einarsen.no/programmer-personality-types-and-why-it-matters-at-all/

This may not be obviously related to naming convention, but please,
read, this is related to “ understanding each others ”

This may throw light on two points :
1) why it appears we encounter difficulties in agreeing about a common
convention
2) why we should agree on a common convention

(both)

A quote from this article :
> That is also a good thing to keep in mind when formatting code for
> readability: if your coding style differs from standard Perl Tidy or
> your company’s coding standard, keep in mind that you are not
> formatting for yourself, but a colleague, maintainer or anonymous
> CPAN downloader. They are more likely to understand a common
> standard than your standard. It sounds obvious, don’t it? I don’t
> think many (any) programmers think like this even so.

Thus the need to agree, which in turn make it less difficult a
situation where yours and others may match

( we may suppose formalization and explicit rationals may help to
agree )

Note : when I've though about posting this quote, I've made the
assumption this is also applicable when peoples are not working for a
common company and even when they are working alone but not in their
strict own purpose

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

[Hibou57 (Yannick Duchêne)]

This one does not give a lot of reasons to rejoice :
http://p.einarsen.no/category/understanding-code/

It simply ends with a “ But do keep in mind that the research is still
a bit patchy, and this is mostly an argument without empirical data. ”

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

[tmoran]

Regarding _Type as lengthing names, Pascal's comment seems appropriate:
"I apologize that this letter is so long, I lacked the time to make it short."

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

[Georg Bauhaus]

Stephen Leake schrieb:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

>> When you see
>>
>> Append (List => List, Element => Element);
>>
>> you don't really know what's being appended to what. 
> 
> In a purely generic context, like in the body of
> Ada.Containers.Indefinite_Doubply_Linked_LIsts, that is precisely what
> you should know.
> 
> What's wrong with that?

First, few people write purely generic code.

Stepanov et al. do.  You do.  Their admirable work has nevertheless
created new words in a new anguage by way of overloading.
(Can I suggest the name  Techlish ?)
Example:
Combine "push" and "onto the back end" to have a mathematician
from Moscow create the word "push_back" for that.  To me,
that is 90� off, never mind.  (Just a speculation about the
origin of push_back.  Absolutely no offense intended!)
And the concatenation "push" & "_back" is about the linguistic
support for the specification of meaning in STL programming
there is!

Unfortunately, when you work for some time on one subject,
its context becomes familiar to you---but not to others;
what is more, and as regards Ada.Containers work, is that the STL
and other generic programs revolve all around (a) generic algorithms,
(b) a certain machine model.  The machine model is necessarily
of its own abstract nature.  It is the starting point
for programming solutions using generic algorithms.  Unfortunately,
neither the STL nor other libraries offer but internally sensible
names.  They all force us to switch from our domain to the
generic machine.  There is a gap in naming mechanisms; everything
is lumped together in slang names and most abstract, fluffy terms,
full of allusions to the theory behind, but lacking a real
mechanism that links the generic composition with the rest of
the program.  Name wise.  We'd need that in order to bridge
the gap between the two naming conventions.

There is therefore potential for tons of questions if all
a "non-generic" programmer sees is "List" or "Size" in all
sorts of places in a program.  These words should be endemic
among generic library authors, yes.  But why anywhere else?


> Op_1 (onto => list, element => object_1);
> Op_2 (from => list, element => object_2);
> Op_3 (container => list, element => object_3);
> 
> It's much easier if it's always "list => list".

Well, ease as an excuse...  I find it much easier to write
C++, fast; C++ at some level is much easier and more
permissive---easier until there is some odd crash
and you look through the large combinatorial array of
generic library names(!) in a long diagnostic message...

I think the ease argument will be interesting if it becomes
clear what the Op_N stand for, respectively.

The third line is notably not overloading the parameter name
"List" and the type name "List".

Cf. valid Eiffel:

   local
      string: STRING
   do
      ...  -- more uses of string and STRING. Or StrINg.

(Somewhat at odds with the 1-name-rule of that language.
I have only a single name space in my brain...)
Is this example as confusing than Op (List : List)?

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

[Georg Bauhaus]

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 "+".

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

[Randy Brukardt]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:uskcz6ahs.fsf@stephe-leake.org...
...
> Here are the similar definitions from
> Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start
> arguing that is a bad abstraction.
>
> package Ada.Containers.Indefinite_Doubly_Linked_Lists is
>
>   type List is tagged private;
>
>   generic
>      with function "<" (Left, Right : Element_Type) return Boolean is <>;
>   package Generic_Sorting is
>
>      function Is_Sorted (Container : List) return Boolean;
>   end Generic_Sorting;
> end Ada.Containers.Indefinite_Doubly_Linked_Lists;
>
> Note that it uses _Type for Element!

If anyone cares, that's because we used a form of Stephen's rules for naming 
these. In this case, we determined that the best name ("Element") should be 
reserved for the operation, as the operation will likely be used many times, 
while the formal type name is hardly ever written in client code (just as a 
name in the instance) -- note this ties into one of the previous threads 
here. We considered using longer names for the operation like "Get_Element", 
"Read_Element", etc., but those just made the name longer without adding 
enough additional information. After all, an important rule is to make names 
long enough to capture all of the critical information, but no longer 
(because there is a point where names get too long for readability).

                     Randy.

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

[Randy Brukardt]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:u8wet6ttv.fsf@stephe-leake.org...
...
>> I do not mean I'm surprised this convention is working fine with the
>> Ada standard packages set, I know there is probably a reason which
>> explains why it works in this one case :
>
> It works for the standard because people are very flexible, and can
> work around quirks like this while convincing themselves it's better.
>
> It would take less effort to use a package if all types followed the
> _Type convention. Then more people would have more time to write more
> Ada code, and we'd take over the world.

This note gave me a good laugh.

At one point, Matt had use "_Type" in all of the names used in the 
containers. There are enough people who hate that convention that we ended 
up changing it. I was surprised by that reaction: Claw uses "_Type" in about 
95% of its types (there are few cases where other suffixes made the "_Type" 
look like pure noise) -- and I don't recall anyone complaining. I would have 
preferred to continue to use "_Type" in most cases, but it isn't that big of 
a deal to me.

                        Randy.

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

[Hibou57 (Yannick Duchêne)]

May be a step to help to go forward : I remember that I oftenly saw,
in some Windows API documentations, something which I feel nice : some
type declarations were coming with a suggested prefix to be used as a
tag indicating the type in the purpose of the Hungarian notation. I'm
not thinking about mapping this exact thing, but it make me thing
about a similar idea.

This may be cool, to provide a small list of suggested names for
concrete instance of generic packages, object instances of a type,
derived type name, etc, when applicable. In a whole, the idea to
provide naming hints beside declarations, whenever a declaration is
subject to later instantiations or later derivations.

This does not solve the question exposed by this topic, but this may
be a tool to use in this area.

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

[Stephen Leake]

"Peter C. Chapin" <pcc482719@gmail.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> wrote in 
> news:u4ope4pqa.fsf@stephe-leake.org:
>
>> Yes, but reading is also important. The _Type suffix is essentially
>> noise when reading; it's only there for the compiler, not the human.
>> So you want to read it as few times as possible, as well as write it
>> as few times as possible.
>
> This seems backwards to me. I could use a type name such as X72efY9 for all 
> the compiler cares. The _Type suffix is most definitely for the human. It 
> says, "Hey! This is the name of a type so keep that in mind when looking at 
> this code."

Well, you can read it that way. But the original reason the _Type
convention got started (at least, as far as I'm concerned) is to solve
the problem of overlapping object and type namespaces.

This is illegal:

    procedure (List : in list);

So we have to add noise to either the object or the type, to keep the
compiler happy. That's all there is to it.

> In the past I used _Type as a suffix for all of my types. However, there 
> are times when that doesn't seem to fit. After all the standard types don't 
> (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc). 

The standard is Just Wrong. But we have to live with it.

-- 
-- Stephe

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

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Stephen Leake schrieb:
>
>> Op_1 (onto => list, element => object_1);
>> Op_2 (from => list, element => object_2);
>> Op_3 (container => list, element => object_3);
>> 
>> It's much easier if it's always "list => list".
>
> Well, ease as an excuse...  I find it much easier to write
> C++, fast; C++ at some level is much easier and more
> permissive---easier until there is some odd crash
> and you look through the large combinatorial array of
> generic library names(!) in a long diagnostic message...

I meant easier in all senses; fewer compiler errors, fewer real
errors, less development time.

> I think the ease argument will be interesting if it becomes
> clear what the Op_N stand for, respectively.

If you start asking about what they stand for, you've missed the
point. I should not have to waste time thinking about that; I know
they come from the list package, so the type is List_Type, and the
parameter name is List. Now I can think about the _other_ parameters.

> Cf. valid Eiffel:
>
>    local
>       string: STRING
>    do
>       ...  -- more uses of string and STRING. Or StrINg.

That is the argument both for and against case sensitivity.

-- 
-- Stephe

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

[Dmitry A. Kazakov]

On Wed, 04 Nov 2009 19:33:58 -0500, Stephen Leake wrote:

> "Peter C. Chapin" <pcc482719@gmail.com> writes:
> 
>> In the past I used _Type as a suffix for all of my types. However, there 
>> are times when that doesn't seem to fit. After all the standard types don't 
>> (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc). 
> 
> The standard is Just Wrong. But we have to live with it.

Huh, it is not too late to introduce:

package Standard is
   ...
   subtype Integer_Type is Integer;
end Standard;

But Know what? "subtype" looks awfully wrong! Should not it be
"subtype_type"? What about

type_type  String_Type is
   array_type (Integer_Type range <>)
      of Character_Type;

(:-))

Consider it this way, if _Type is felt appropriate then that is
semantically equivalent to types having a separate name space. The latter
could be introduced in Ada at any time, being fully backward compatible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Niklas Holsti]

Dmitry A. Kazakov wrote:

> Consider it this way, if _Type is felt appropriate then that is
> semantically equivalent to types having a separate name space. The latter
> could be introduced in Ada at any time, being fully backward compatible.

I'm not sure about the backward compatibility. For one thing, the 'Size 
attribute may have a different value for a type and for an object of the 
type. This means that given an object declaration "List : List", where 
the latter List is a type name, the expression List'Size would be 
ambiguous and could have a different value for the object List and the 
type List.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Dmitry A. Kazakov]

On Thu, 05 Nov 2009 10:48:51 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
> 
>> Consider it this way, if _Type is felt appropriate then that is
>> semantically equivalent to types having a separate name space. The latter
>> could be introduced in Ada at any time, being fully backward compatible.
> 
> I'm not sure about the backward compatibility. For one thing, the 'Size 
> attribute may have a different value for a type and for an object of the 
> type. This means that given an object declaration "List : List", where 
> the latter List is a type name, the expression List'Size would be 
> ambiguous and could have a different value for the object List and the 
> type List.

Yes, it is ambiguous, but backward compatible.

Another disadvantage of a separate name space were barring types as
first-class objects. I don't know how actual the latter might be.

I have no clear opinion on separate name space for types. Clearly if
considered, it should be accompanied with the separate name spaces for
labels and package names.

Further, the problem of what to do with

   type T_Ptr is access T;
   type T_Ref is access constant T;
   type T_Class_Ptr is access T'Class;

will remain.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Georg Bauhaus]

Stephen Leake schrieb:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> Stephen Leake schrieb:
>>
>>> Op_1 (onto => list, element => object_1);
>>> Op_2 (from => list, element => object_2);
>>> Op_3 (container => list, element => object_3);
...
> I meant easier in all senses; fewer compiler errors, fewer real
> errors, less development time.

What about the time needed to understand the program,
or to communicate its meaning, and be it just the outlining
of the don't-care parts absent from the naming scheme?

>> I think the ease argument will be interesting if it becomes
>> clear what the Op_N stand for, respectively.
> 
> If you start asking about what they stand for, you've missed the
> point. I should not have to waste time thinking about that; I know

Here we are...  You may know, but I don't; if I am important
as a user of your programs, I'd kindly ask you to have the
knowledge shine through the names.


> they come from the list package, so the type is List_Type, and the
> parameter name is List. Now I can think about the _other_ parameters.

In this case (two things we know: we have a list package and
a list type), it is possible instead to give, first,

  package List is

     type Container is private;

     procedure Sort (Elements : in out Container; ...);

and, second, a rule that forces programmers to use a prefix
in clients, to make sure the type of "Container" can be seen
immediately:

   procedure Some_Client
     (<problem-domain-name> : List.Container; ...);

   Left_Queue, Right_Queue : List.Container;



>> Cf. valid Eiffel:
>>
>>    local
>>       string: STRING
>>    do
>>       ...  -- more uses of string and STRING. Or StrINg.
> 
> That is the argument both for and against case sensitivity.

No, the argument is that a language allowing the same name
("string") to stand for different things, for both objects and
types, in the same scope will necessarily add another dimension
to the confusion space.  Specifically, "string" and "STRING" do
not denote the same thing *even* *though* the language
Eiffel is case insensitive, like Ada.  The lexical overlap
of names in separate name spaces plus the case insensitivity
add to to the combinatorial explosives in front of the
reader.
(Of course, in real life forcing good standalone names
are simply(*) is countered with "works for me".)

procedure Something (List : in out List; ....), with a
namespace for objects and another for types, just places
the burden of disambiguation on the reader. Yes, they need
to do that sometimes; the author might not forsee the
necessity.  To me, it does not matter that the author of
Something happens to know which is which.

Continuing Dmitry's argument

  package List_Package is

      type List_Type is private;


      function List_Function return List_Type;

  end List_Package;

Here, I must choose List_Function because Ada lets me have
only one namespace.  So I need to add noise, but
I (the author) know that the function is just
returning a new List, no need to think of a good name,
since I know what I am doing... What am I doing?

What would clients look like?

-----
(*) "Simply" is a trade mark of Betrand Meyer. :)
(There are simply too many occurrences of "simply" in
OOSC2 to think otherwise...)

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

[Vincent Marciante]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:u1vkdrert.fsf@stephe-leake.org...
> "Peter C. Chapin" <pcc482719@gmail.com> writes:
>
>> Stephen Leake <stephen_leake@stephe-leake.org> wrote in
>> news:u4ope4pqa.fsf@stephe-leake.org:
>>
>>> Yes, but reading is also important. The _Type suffix is essentially
>>> noise when reading; it's only there for the compiler, not the human.
>>> So you want to read it as few times as possible, as well as write it
>>> as few times as possible.
>>
>> This seems backwards to me. I could use a type name such as X72efY9 for 
>> all
>> the compiler cares. The _Type suffix is most definitely for the human. It
>> says, "Hey! This is the name of a type so keep that in mind when looking 
>> at
>> this code."
>
> Well, you can read it that way. But the original reason the _Type
> convention got started (at least, as far as I'm concerned) is to solve
> the problem of overlapping object and type namespaces.
>
> This is illegal:
>
>    procedure (List : in list);
>
> So we have to add noise to either the object or the type, to keep the
> compiler happy. That's all there is to it.

That is not necessary:

package sdgfkjasf is -- or whayever

   type List is ...

   procedure jsdfks (List : sdgfkjasf.List);

   ...


>> In the past I used _Type as a suffix for all of my types. However, there
>> are times when that doesn't seem to fit. After all the standard types 
>> don't
>> (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc).
>
> The standard is Just Wrong. But we have to live with it.
>
> -- 
> -- Stephe


Vinny 

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

[Stephen Leake]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Dmitry A. Kazakov wrote:
>
>> Consider it this way, if _Type is felt appropriate then that is
>> semantically equivalent to types having a separate name space. The latter
>> could be introduced in Ada at any time, being fully backward compatible.
>
> I'm not sure about the backward compatibility. For one thing, the
> Size attribute may have a different value for a type and for an object
> of the type. This means that given an object declaration "List :
> List", where the latter List is a type name, the expression List'Size
> would be ambiguous and could have a different value for the object
> List and the type List.

The definition of "backward compatible" is "all existing legal
programs will still be legal".

This ambiguity does not exist in existing legal programs.

It is a good reason not to have separate name spaces; how would we
resolve the ambiguity?

-- 
-- Stephe

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

[Stephen Leake]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Stephen Leake schrieb:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>> 
>>> Stephen Leake schrieb:
>>>
>>>> Op_1 (onto => list, element => object_1);
>>>> Op_2 (from => list, element => object_2);
>>>> Op_3 (container => list, element => object_3);
> ...
>> I meant easier in all senses; fewer compiler errors, fewer real
>> errors, less development time.
>
> What about the time needed to understand the program,
> or to communicate its meaning, and be it just the outlining
> of the don't-care parts absent from the naming scheme?

I don't understand why you are excluding the naming scheme. Naming
conventions are huge gain in understanding.

If I am reading a package that defines an abstract type List_Type, and
all primitive operations on List_Type have a parameter named List,
then I don't have to try to understand whatever name got used instead
of List.

>>> I think the ease argument will be interesting if it becomes
>>> clear what the Op_N stand for, respectively.
>> 
>> If you start asking about what they stand for, you've missed the
>> point. I should not have to waste time thinking about that; I know
>
> Here we are...  You may know, but I don't; if I am important
> as a user of your programs, I'd kindly ask you to have the
> knowledge shine through the names.

The names of the Op_N, sure. The name of the List parameter is
unlikely to add any information.

If there is more than one List paramter (say for Copy, or Splice),
then they need better names, of course.

>> they come from the list package, so the type is List_Type, and the
>> parameter name is List. Now I can think about the _other_ parameters.
>
> In this case (two things we know: we have a list package and
> a list type), it is possible instead to give, first,
>
>   package List is
>
>      type Container is private;
>
>      procedure Sort (Elements : in out Container; ...);
>
> and, 

Why is this better? It's just a different convention. If you follow it
uniformly, it will be just as good as List : in out List_Type.

> second, a rule that forces programmers to use a prefix in clients,
> to make sure the type of "Container" can be seen immediately:
>
>    procedure Some_Client
>      (<problem-domain-name> : List.Container; ...);
>
>    Left_Queue, Right_Queue : List.Container;

What if the problem domain is "any list"? We keep pointing this out,
people keep ignoring it.

List.Container is much longer than it needs to be. But that's the
"don't use 'use'" argument.

>>> Cf. valid Eiffel:
>>>
>>>    local
>>>       string: STRING
>>>    do
>>>       ...  -- more uses of string and STRING. Or StrINg.
>> 
>> That is the argument both for and against case sensitivity.
>
> No, the argument is that a language allowing the same name
> ("string") to stand for different things, for both objects and
> types, in the same scope will necessarily add another dimension
> to the confusion space.  Specifically, "string" and "STRING" do
> not denote the same thing *even* *though* the language
> Eiffel is case insensitive, like Ada.  

That makes no sense. Ah; Eiffel has separate type and object name
spaces. So I don't understand the original example; what was the
point?

Yes, this is an example of name overloading. Overloading, like any
good thing, can be abused.

> The lexical overlap of names in separate name spaces plus the case
> insensitivity add to to the combinatorial explosives in front of the
> reader. (Of course, in real life forcing good standalone names are
> simply(*) is countered with "works for me".)

That is the argument against case insensitivity. I like GNAT's
solution to that; issue a warning when an identifier has different
casing than the first use.

> procedure Something (List : in out List; ....), with a
> namespace for objects and another for types, just places
> the burden of disambiguation on the reader. 

Yes. But it is a very small burden, pretty much the same as having to
read _Type. 

The syntax provides all the information necessary; Object : Type.

> Continuing Dmitry's argument
>
>   package List_Package is
>
>       type List_Type is private;
>
>
>       function List_Function return List_Type;
>
>   end List_Package;
>
> Here, I must choose List_Function because Ada lets me have
> only one namespace.  So I need to add noise, but
> I (the author) know that the function is just
> returning a new List, no need to think of a good name,
> since I know what I am doing... What am I doing?

I don't understand your point. No one has suggested choosing generic
names for functions; clearly they need to indicate what the function
does. If this function returns a new empty list, I would call it
New_Empty_List.

Hmm. I guess you are pointing out that package names, subprogram
names, object names, and type names all share the same namespace.
Since we feel the need to add noise to types, why don't we feel the
same need to add noise to packages and subprograms?

The answer is we just don't :).

There are far fewer package names than other names, and come from the
domain, so it's not hard to come up with unique names. Making them
plural and everything else singular works pretty well.

Subprogram names tend to be more specific than parameters of an abstract
type.

I sometimes have package names that collide with enumeration
identifiers:

package Root_Serial_IO is

    type Supported_Cards_Type is (Motorola_1, Intel_1,
    national_semiconductor_42);

    type Device_Type is abstract tagged private;

    ...
end Root_Serial_IO;

then I want child packages with the names Root_Serial_IO.Motorola_1
etc; that causes ambiguities, and sometimes ends up being unworkable.

-- 
-- Stephe

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

[Niklas Holsti]

Stephen Leake wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> Dmitry A. Kazakov wrote:
>>
>>> Consider it this way, if _Type is felt appropriate then that is
>>> semantically equivalent to types having a separate name space. The latter
>>> could be introduced in Ada at any time, being fully backward compatible.
>> I'm not sure about the backward compatibility. For one thing, the
>> Size attribute may have a different value for a type and for an object
>> of the type. This means that given an object declaration "List :
>> List", where the latter List is a type name, the expression List'Size
>> would be ambiguous and could have a different value for the object
>> List and the type List.
> 
> The definition of "backward compatible" is "all existing legal
> programs will still be legal".

Yes, you and Dmitry are right, it would be backward compatible in this 
sense (which is the common sense). I was thinking that using the same 
names for types and objects would create problems, for example this 
ambiguity, and so it would not be "compatible" to take an existing legal 
program and change type names by, for example, removing "_Type" suffixes.

> This ambiguity does not exist in existing legal programs.

Agreed.

> It is a good reason not to have separate name spaces; how would we
> resolve the ambiguity?

Right, that was the problem I had in mind. One way would be to have two 
different attributes, 'Size for objects and 'Type_Size for types. But 
that causes backward-compatibility problems unless 'Size is also 
accepted for types if the name before the 'Size is unambiguously a type 
name. It may also be difficult for compilers to resolve ambiguous names 
based on the kind of attribute applied to the name.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Dmitry A. Kazakov]

On Fri, 06 Nov 2009 04:54:46 -0500, Stephen Leake wrote:

> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> Dmitry A. Kazakov wrote:
>>
>>> Consider it this way, if _Type is felt appropriate then that is
>>> semantically equivalent to types having a separate name space. The latter
>>> could be introduced in Ada at any time, being fully backward compatible.
>>
>> I'm not sure about the backward compatibility. For one thing, the
>> Size attribute may have a different value for a type and for an object
>> of the type. This means that given an object declaration "List :
>> List", where the latter List is a type name, the expression List'Size
>> would be ambiguous and could have a different value for the object
>> List and the type List.
> 
> The definition of "backward compatible" is "all existing legal
> programs will still be legal".
> 
> This ambiguity does not exist in existing legal programs.

And it will not be imposed there by introducing a separation, because
presently such names collide.

> It is a good reason not to have separate name spaces; how would we
> resolve the ambiguity?

As always by using full names. Note that the argument that some of such
names are still ambiguous does not really work, because this is already so
in Ada. For example, overloaded subprograms and literals may have
indistinguishable full names. So this problem must be addressed anyway. The
traditional Ada way would be a qualified expression:

   (type'(T))'Size

This returns us back to a more important argument against separate name
spaces. Do we really want to have types second-class citizens forever? Are
we sure that a type never ever appear in a context of an object? A
qualified expression at least suggests that a type is an object.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Stephen Leake]

"Vincent Marciante" <vmarciante@decilog.com> writes:

> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
> news:u1vkdrert.fsf@stephe-leake.org...
>> This is illegal:
>>
>>    procedure (List : in list);
>>
>> So we have to add noise to either the object or the type, to keep the
>> compiler happy. That's all there is to it.
>
> That is not necessary:
>
> package sdgfkjasf is -- or whayever
>
>    type List is ...
>
>    procedure jsdfks (List : sdgfkjasf.List);
>
>    ...

That's the first time I've seen that suggestion. It's very
interesting. The package name has to show up every time the type is
paired with an object of the same name. But in other situations, the
package name can be left off.

So this ends up being less noise than appending _Type everywhere.

Just to be pedantic, it _is_ adding noise. It's just a different form
of noise than _Type.

I'll have to try it in a semi-real project. I've been using _Type for
over 15 years, so it will take some effort :).

It's interesting why no one seems to have thought of this before. In
general, the way to resolve ambiguities in Ada is to use more of the
full name. Somehow that never occured to me in this context.

-- 
-- Stephe

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

[Hibou57 (Yannick Duchêne)]

On 6 nov, 11:26, Stephen Leake <stephen_le...@stephe-leake.org> wrote:
> "Vincent Marciante" <vmarcia...@decilog.com> writes:
> > "Stephen Leake" <stephen_le...@stephe-leake.org> wrote in message
> >news:u1vkdrert.fsf@stephe-leake.org...
> >> This is illegal:
>
> >>    procedure (List : in list);
>
> >> So we have to add noise to either the object or the type, to keep the
> >> compiler happy. That's all there is to it.
>
> > That is not necessary:
>
> > package sdgfkjasf is -- or whayever
>
> >    type List is ...
>
> >    procedure jsdfks (List : sdgfkjasf.List);
>
> >    ...
>
> That's the first time I've seen that suggestion. It's very
> interesting. The package name has to show up every time the type is
> paired with an object of the same name. But in other situations, the
> package name can be left off.
>
> So this ends up being less noise than appending _Type everywhere.
>
> Just to be pedantic, it _is_ adding noise. It's just a different form
> of noise than _Type.
>
> I'll have to try it in a semi-real project. I've been using _Type for
> over 15 years, so it will take some effort :).
>
> It's interesting why no one seems to have thought of this before.
Perhaps because this is not to be applied in a constant manner

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

[Georg Bauhaus]

On 11/6/09 11:26 AM, Stephen Leake wrote:
> "Vincent Marciante"<vmarciante@decilog.com>  writes:
>

>> package sdgfkjasf is -- or whayever
>>
>>     type List is ...
>>
>>     procedure jsdfks (List : sdgfkjasf.List);
>>
>>     ...
>
> That's the first time I've seen that suggestion.

For objects, this is how task components are matched
with acceptor parameters in John Barnes's book (not
the exact same thing as object names and type names,
for sure, but the prefix is present):

    task body W is
      A: T;
    begin
      accept Foo (A: T) do
        W.A := A;
      end Foo;



> It's interesting why no one seems to have thought of this before.

My guess is that it has to do with expectations:
Many readers will have seen both X and X_Type as type names.
Consequently, both forms can denote a type in their expectation.
This expectation would have to be unlearned and replaced
with yet another expectation, a somewhat idiosyncratic one:
that X denotes an object and P.X denotes a type, as you
have outlined.
At first sight this seems better than _Type, since P.X
does not force the mixture of solution words like "X" and
"meta names" from the Ada language description like "_Type".

But starting from the first expectation, what really matters
is X.  How can we map exactly one meaning to exactly one
kind of entity presuming it is the direct name that matters?

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

[Georg Bauhaus]

On 11/6/09 11:14 AM, Stephen Leake wrote:

>> In this case (two things we know: we have a list package and
>> a list type), it is possible instead to give, first,
>>
>>    package List is
>>
>>       type Container is private;
>>
>>       procedure Sort (Elements : in out Container; ...);
>>
>> and,
>
> Why is this better? It's just a different convention.   If you follow it
> uniformly, it will be just as good as List : in out List_Type.

The convention differs in that none of the identifiers overlap.
For me, List and List_Type are just not different enough (the first
being a prefix of the second only in a very mechanical sense BTW):
I need to combine programs whose authors have followed
different naming conventions.  In this case I have to take
responsibility for disambiguating all occurrences of "List"
WRT to their denoting a type or an object.

Yes, if one author chooses to name the package "List" and the
type "Container", another chooses type name "List", the situation
is equally imperfect.  But at least, I feel like the authors
have picked names whose differences is more than a dry, formal
suffix like "_Type": the difference is in the "domain part" of
the type name.


>> second, a rule that forces programmers to use a prefix in clients,
>> to make sure the type of "Container" can be seen immediately:
>>
>>     procedure Some_Client
>>       (<problem-domain-name>  : List.Container; ...);
>>
>>     Left_Queue, Right_Queue : List.Container;
>
> What if the problem domain is "any list"? We keep pointing this out,
> people keep ignoring it.


    procedure Some_Client  (Any_List : List.Container; ...);
    procedure Some_Client  (Any_List : List; ...);
    procedure Some_Client  (Any_List : Sequence; ...);


This is what I meant by hinting to the domain. (It seems possible
to argue that the word "Any" has a role to play in type names.
I haven't seen "any" as part of a type name, though, only as a
standalone type name, in Eiffel.)  "Any_List" is just explicitly
referring to "any list"; I find "list" for "any list" leaves
more questions to be asked, given the ubiquitous use of "list".
A resolution requires assuming that some convention can
decide on the interpretation.

At least, "Any", unlike "_Type" is not from the Ada language
vocabulary.


> List.Container is much longer than it needs to be. But that's the
> "don't use 'use'" argument.
>
>>>> Cf. valid Eiffel:
>>>>
>>>>     local
>>>>        string: STRING
>>>>     do
>>>>        ...  -- more uses of string and STRING. Or StrINg.
> Ah; Eiffel has separate type and object name
> spaces. So I don't understand the original example; what was the
> point?

In a dozen or so lines of subprogram text, the sequence of
characters "String" can refer to two different concepts, in Eiffel,
when you have declared string : STRING, an object and a type.
The reader, on seeing "String" in the lines following the
declaration, is forced to infer from context which concept was
meant.  Sure, this is possible, not even difficult if you know
the language, as every Eiffel compiler demonstrates.  But I don't
want to assume the role of the compiler just to see what
"String" stands for.
This is name overloading of two language concepts in the
very same inner scope.  Even when this if formally just
fine, what's the point?


> Yes, this is an example of name overloading. Overloading, like any
> good thing, can be abused.

Assuming separate namespaces for objects and types,
I can imagine programmers who find "string : STRING"
very clever.  Or just a good match for some twisted programming
trick.  Why make cleverness, or the appearance thereof,
easy to achieve?

For comparison, imagine a Prolog program that uses Yellow in the
parameter list and yellow in the definition.  A Prolog fan knows
that "Yellow" is not bound AFAIK, since it starts with a capital
letter "Y"; "yellow", starting with a small "f", must have
been bound somewhere.  In a sense, Yellow and yellow
live in different namespaces.  The image of that definition
does confuse me, but I am not sure whether this style is
frowned upon in the Prolog community.   I hope so.
The rule about upper case first letters for Prolog variables
has been criticized.

>> procedure Something (List : in out List; ....), with a
>> namespace for objects and another for types, just places
>> the burden of disambiguation on the reader.
>
> Yes. But it is a very small burden, pretty much the same as having to
> read _Type.

I have to disagree here, for reasons given here and in another post.


> Hmm. I guess you are pointing out that package names, subprogram
> names, object names, and type names all share the same namespace.
> Since we feel the need to add noise to types, why don't we feel the
> same need to add noise to packages and subprograms?
>
> The answer is we just don't :).

True enough.  Yet there are those who feel the need to not
add _Type to type names, too, at least when the suffix
is used to "free" that same name for objects nearby.

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

[Vincent Marciante]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:uskcsne3h.fsf@stephe-leake.org...
> "Vincent Marciante" <vmarciante@decilog.com> writes:
>
>> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
>> news:u1vkdrert.fsf@stephe-leake.org...
>>> This is illegal:
>>>
>>>    procedure (List : in list);
>>>
>>> So we have to add noise to either the object or the type, to keep the
>>> compiler happy. That's all there is to it.
>>
>> That is not necessary:
>>
>> package sdgfkjasf is -- or whayever
>>
>>    type List is ...
>>
>>    procedure jsdfks (List : sdgfkjasf.List);
>>
>>    ...
>
> That's the first time I've seen that suggestion.

Or maybe you forgot!
The following is part of a old discusion to
which you contributed:


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Newsgroups: comp.lang.ada
From: "Vincent Marciante" <marciant_rem...@li.net>
Date: Fri, 5 Oct 2001 15:17:35 -0400
Local: Fri, Oct 5 2001 2:17 pm
Subject: Re: on package naming, should the word "_pkg" be part of it?


"Jeffrey Carter" <jeffrey.car...@boeing.com> wrote in message


<snip>


> John McCabe wrote:

> >    type Car_Type is
> >        record
> >           ....
> >        end record;


> >    procedure DoSomething (Car : in out Car_Type);


> > could be replaced by:


> >    type Car is
> >        record
> >           ....
> >        end record;


> >    procedure DoSomething (The_Car : in out Car);


> I recall reading articles about the psychology of understanding programs
> (sorry, Robert Dewar, I don't have references for this, either.
> Hopefully it's not just random neurons firing in my brain) that stated
> that the first few characters of an identifier are the most important in
> determining what you're reading. Having identifiers that are identical
> for the first few characters requires more time and effort to
> understand, and results in more errors in understanding.


> Although both _Type and The_ are ways to resolve the type/parameter name
> conflict, The_ is worse because it makes the first four characters of
> every parameter name the same.


> I make the type name reflect what the type contains. For example


> type Car_Info ...


> procedure P (Car : in Car_Info ...


> This is not a popular approach, though, because it requires thought
> about every type name.


> -- 
> Jeffrey Carter



What about the following:

package XYZ is


     type Car ...


     procedure P (Car : in XYZ.Car ...


-- 
Vinny




<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



> It's very interesting. The package name has to show up every time the type 
> is
> paired with an object of the same name. But in other situations, the
> package name can be left off.
>
> So this ends up being less noise than appending _Type everywhere.
>
> Just to be pedantic, it _is_ adding noise. It's just a different form
> of noise than _Type.
>
> I'll have to try it in a semi-real project. I've been using _Type for
> over 15 years, so it will take some effort :).
>
> It's interesting why no one seems to have thought of this before. In
> general, the way to resolve ambiguities in Ada is to use more of the
> full name. Somehow that never occured to me in this context.
>
> -- 
> -- Stephe 

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

[Stephen Leake]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> On 11/6/09 11:14 AM, Stephen Leake wrote:
>
>>> second, a rule that forces programmers to use a prefix in clients,
>>> to make sure the type of "Container" can be seen immediately:
>>>
>>>     procedure Some_Client
>>>       (<problem-domain-name>  : List.Container; ...);
>>>
>>>     Left_Queue, Right_Queue : List.Container;
>>
>> What if the problem domain is "any list"? We keep pointing this out,
>> people keep ignoring it.
>
>
>    procedure Some_Client  (Any_List : List.Container; ...);
>    procedure Some_Client  (Any_List : List; ...);
>    procedure Some_Client  (Any_List : Sequence; ...);
>
>
> This is what I meant by hinting to the domain. 

Surely these are in different packages? Packages Containers, Lists,
and Sequences?

Then it is the package name that gives the domain; that works for me.

> At least, "Any", unlike "_Type" is not from the Ada language
> vocabulary.

One reason to use "_Type" is precisely _because_ it means "Ada type";
there's no need to wonder about what it means.

>>>>> Cf. valid Eiffel:
>>>>>
>>>>>     local
>>>>>        string: STRING
>>>>>     do
>>>>>        ...  -- more uses of string and STRING. Or StrINg.
>> Ah; Eiffel has separate type and object name
>> spaces. So I don't understand the original example; what was the
>> point?
>
> In a dozen or so lines of subprogram text, the sequence of
> characters "String" can refer to two different concepts, in Eiffel,
> when you have declared string : STRING, an object and a type.

So the case is not important; why did you introduce it? 

In another post, someone said Eiffel required <> around types; is that
not true?

> The reader, on seeing "String" in the lines following the
> declaration, is forced to infer from context which concept was
> meant. Sure, this is possible, not even difficult if you know the
> language, as every Eiffel compiler demonstrates.

When designing naming conventions, I always assume you know the
language.

In a language like C, sometimes we use conventions that are not
strictly necessary, because the syntax is so bad.

I have not used Eiffel, but if I assume the syntax distinguishing type
from object is as good as in Ada, then I don't see a problem here.

> But I don't want to assume the role of the compiler just to see what
> "String" stands for. This is name overloading of two language
> concepts in the very same inner scope. Even when this if formally
> just fine, what's the point?

The point, as always in this discussion, is to save time making up
separate names for types and objects.

>> Yes, this is an example of name overloading. Overloading, like any
>> good thing, can be abused.
>
> Assuming separate namespaces for objects and types,
> I can imagine programmers who find "string : STRING"
> very clever.  Or just a good match for some twisted programming
> trick.  Why make cleverness, or the appearance thereof,
> easy to achieve?

Good programmers will just find it natural; why introduce twisted
programmers into this?

-- 
-- Stephe

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

[Stephen Leake]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> On 11/6/09 11:26 AM, Stephen Leake wrote:
>> "Vincent Marciante"<vmarciante@decilog.com>  writes:
>>
>
>>> package sdgfkjasf is -- or whayever
>>>
>>>     type List is ...
>>>
>>>     procedure jsdfks (List : sdgfkjasf.List);
>>>
>>>     ...
>>
>> It's interesting why no one seems to have thought of this before.
>
> My guess is that it has to do with expectations:
> Many readers will have seen both X and X_Type as type names.
> Consequently, both forms can denote a type in their expectation.
> This expectation would have to be unlearned and replaced
> with yet another expectation, a somewhat idiosyncratic one:
> that X denotes an object and P.X denotes a type, as you
> have outlined.

It's only "idiosyncratic" because it's new.

X is still a type name; this is actually a more "normal Ada way" of
resolving a name ambiguity.

> At first sight this seems better than _Type, since P.X does not
> force the mixture of solution words like "X" and "meta names" from
> the Ada language description like "_Type".
>
> But starting from the first expectation, what really matters
> is X.  How can we map exactly one meaning to exactly one
> kind of entity presuming it is the direct name that matters?

In general, Ada does _not_ require exactly one meaning for one
identifier; that's what this discussion is all about.

-- 
-- Stephe

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

[Stephen Leake]

"Vincent Marciante" <vmarciante@decilog.com> writes:

> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
> news:uskcsne3h.fsf@stephe-leake.org...
>> "Vincent Marciante" <vmarciante@decilog.com> writes:
>>
>>> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
>>> news:u1vkdrert.fsf@stephe-leake.org...
>>>> This is illegal:
>>>>
>>>>    procedure (List : in list);
>>>>
>>>> So we have to add noise to either the object or the type, to keep the
>>>> compiler happy. That's all there is to it.
>>>
>>> That is not necessary:
>>>
>>> package sdgfkjasf is -- or whayever
>>>
>>>    type List is ...
>>>
>>>    procedure jsdfks (List : sdgfkjasf.List);
>>>
>>>    ...
>>
>> That's the first time I've seen that suggestion.
>
> Or maybe you forgot!

Always possible.

> The following is part of a old discusion to which you contributed:

<snip>

I don't see your point; that old discussion does _not_ propose using
<package>.<type> to resolve the ambiguity. 

-- 
-- Stephe

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

[Georg Bauhaus]

On 11/7/09 6:49 AM, Stephen Leake wrote:

> One reason to use "_Type" is precisely _because_ it means "Ada type";
> there's no need to   wonder about what it means.

But the language meaning of "type" does not help with
the mentioned Message_Type_Type?
If I stubbornly follow your conventions as I understand them,
I'd have to write

   procedure Something (Message_Type : in Message_Type_Type);
or
   procedure Something (Message_Type : in Message_Types.Message_Type);

wouldn't I?  (I speculate that one could add a remark about
first class type objects here, as per Dmitry's suggestion.
More confusion.)


>>>>>> Cf. valid Eiffel:
>>>>>>
>>>>>>      local
>>>>>>         string: STRING
>>>>>>      do
>>>>>>         ...  -- more uses of string and STRING. Or StrINg.
>>> Ah; Eiffel has separate type and object name
>>> spaces. So I don't understand the original example; what was the
>>> point?
>>
>> In a dozen or so lines of subprogram text, the sequence of
>> characters "String" can refer to two different concepts, in Eiffel,
>> when you have declared string : STRING, an object and a type.
>
> So the case is not important; why did you introduce it?

The "String : String" part of the declaration means
  -object-named-String- : -type-named-String-
in Eiffel.  The very same word names both the
object and the type.  Characters case is important to the
reader, however (you have mentioned GNAT's warnings).
The writer may like to use case distinction to "disambiguate"
the same sequence of letters.  That's fine as long as you
live in a single universe of formal names, like when you are
working on the same set of Ada programs for months, and
never need to look elsewhere.


> In another post, someone said Eiffel required<>  around types; is that
> not true?

I mentioned Dylan where you would write string : <string>;
In Eiffel, and in hypothetical 2-namespace-Ada you write STring: STring,
if you want to. The visual difference is none.  Is the difference in
meaning perfectly clear in the body lines following the declaration?


> The point, as always in this discussion, is to save time making up
> separate names for types and objects.
>
>>> Yes, this is an example of name overloading. Overloading, like any
>>> good thing, can be abused.
>>
>> Assuming separate namespaces for objects and types,
>> I can imagine programmers who find "string : STRING"
>> very clever.  Or just a good match for some twisted programming
>> trick.  Why make cleverness, or the appearance thereof,
>> easy to achieve?
>
> Good programmers will just find it natural; why introduce twisted
> programmers into this?

OK, I thought that the design of a general purpose programming
language, together with the naming conventions surrounding it,
should be manageable by a general public of programmers, not just
"programmers who find this natural" =:def "good programmers".
Some good programmers, in fact language makers,
have made String : String impossible.  Supposedly, then, they
did not deem String : String a natural thing, even though they
were good programmers.

Here is an analogous example.
The argument (be a better programmer if you want to use our
language properly) is popular.  Whenever I had the courage to
mention that there are sharp corners in C and that,
therefore, we should be expecting these corners
to cause trouble, I heard it: programmers causing trouble
in C programs lack education! Well...
Proof of trouble is the weekly CVE report about C programs
and the type "int".  That's am empirical fact.  QED.

Is it an empirical fact that most programmers lack education?
Or does C have some dangerous imperfections?
The typical response is a exaggeration of your question: Why count
stupid non-C-knowing less than excellent programmers
in the select set of programmers-finding-C-natural who
know by heart the C standard and the compiler documentation?
("Because we live on planet earth!" is what I think, then.
"A language, or a naming convention, should respect this fact.")

Before turning back to Ada and naming conventions, let me
stress the analogy, regarding Ada programmer skills.
What about C programmers who are writing programs even
though they don't know every detail about C's "int"?
They are writing programs controlling machines that
affect our daily lives.  Should they not?  Should we
shape a language and conventions around the idea that "int"
is fine in the hands of brilliant programmers and that
other programmers should seek different occupations?
In any case, the above speakers will not accept the group of normal
programmers as a premise; mostly because doing so will show
C's imperfections when in the hands of imperfect programmers,
*to* *a* *degree* that is largely caused by C---it could be
less (which is why Cyclone is different, I should think).
Those speaking in favor of C's "idiosyncrasies" like "int" deny
the normal situation of imperfect programming...
This is why I am skeptical of naming conventions that need
twisted knowledge, like List : in out List.

My claim is that if Ada allows List : in out List, then there
will be a growing number of programmers who "save time making
up separate names" and routinely use T : T.
To support this claim, I think I can point at another time saver:
Anonymous "access" was introduced with Ada 2005.  People
like it.  One reason is that it saves time making up
pointer type names.
(Viz. why, instead of declaring pointer types, not just add Foo*
and &Bar like we are used to?  Of course,  I meant "X : access Foo;"
and "Bar'Unchecked_Access"?  Easy.  Saves time.)

IMO, the effect of naming conventions is first and foremost an
effect on human Ada programmers, caused by human programmers.
The language definition will influence naming conventions,
but this is accidental.

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

[Georg Bauhaus]

On 11/7/09 3:28 PM, Georg Bauhaus wrote:

>>>>>>> Cf. valid Eiffel:
>>>>>>>
>>>>>>> local
>>>>>>> string: STRING
>>>>>>> do
>>>>>>> ... -- more uses of string and STRING. Or StrINg.
>>>> Ah; Eiffel has separate type and object name
>>>> spaces. So I don't understand the original example; what was the
>>>> point?
>>>
>>> In a dozen or so lines of subprogram text, the sequence of
>>> characters "String" can refer to two different concepts, in Eiffel,
>>> when you have declared string : STRING, an object and a type.
>>
>> So the case is not important; why did you introduce it?
>
> The "String : String" part of the declaration means
> -object-named-String- : -type-named-String-
> in Eiffel. The very same word names both the
> object and the type. Characters case is important to the
> reader, however (you have mentioned GNAT's warnings).
> The writer may like to use case distinction to "disambiguate"
> the same sequence of letters. That's fine as long as you
                                   will be
> live in a single universe of formal names, like when you are
> working on the same set of Ada programs for months, and
                         Ada-with-two-namespace
> never need to look elsewhere.
    and [Ss][Tt][Rr][Ii][Nn][Gg]'s meaning is easily seen
from immediate context.

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

[Stephen Leake]

Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:

> On 11/7/09 6:49 AM, Stephen Leake wrote:
>
>> One reason to use "_Type" is precisely _because_ it means "Ada type";
>> there's no need to   wonder about what it means.
>
> But the language meaning of "type" does not help with
> the mentioned Message_Type_Type?
> If I stubbornly follow your conventions as I understand them,
> I'd have to write
>
>   procedure Something (Message_Type : in Message_Type_Type);
> or
>   procedure Something (Message_Type : in Message_Types.Message_Type);
>
> wouldn't I?  

Yes. This is the only special case, and usually I just stubbornly
follow the convention. You get used to it.

Another choice is to use Message_Label instead; 

   procedure Something (Message_Label : in Message_Label_Type);

>> In another post, someone said Eiffel required<>  around types; is that
>> not true?
>
> I mentioned Dylan where you would write string : <string>;

Ah, sorry for the confusion.

> 
> In Eiffel, and in hypothetical 2-namespace-Ada you write STring:
> STring, if you want to. The visual difference is none. Is the
> difference in meaning perfectly clear in the body lines following
> the declaration?

No, there are times when either an object or a type could be used, in
attributes. Which is probably why Ada has a single namespace.

>>>> Yes, this is an example of name overloading. Overloading, like any
>>>> good thing, can be abused.
>>>
>>> Assuming separate namespaces for objects and types,
>>> I can imagine programmers who find "string : STRING"
>>> very clever.  Or just a good match for some twisted programming
>>> trick.  Why make cleverness, or the appearance thereof,
>>> easy to achieve?
>>
>> Good programmers will just find it natural; why introduce twisted
>> programmers into this?
>
> OK, I thought that the design of a general purpose programming
> language, together with the naming conventions surrounding it,
> should be manageable by a general public of programmers, not just
> "programmers who find this natural" =:def "good programmers".
> Some good programmers, in fact language makers,
> have made String : String impossible.  

Yes, for good reasons.

> Supposedly, then, they did not deem String : String a natural thing,
> even though they were good programmers.

That's a stretch! Avoiding actual ambiguities is a better reason. But
I don't presume to read their minds. It would be interesting to read
some rationale on this; I don't think there is any in the Ada Language
Manual. 

> Before turning back to Ada and naming conventions, let me
> stress the analogy, regarding Ada programmer skills.
> What about C programmers who are writing programs even
> though they don't know every detail about C's "int"?

They are undereducated programmers, by definition.

> They are writing programs controlling machines that affect our daily
> lives. Should they not? 

They should not.

> Should we shape a language and conventions around the idea that
> "int" is fine in the hands of brilliant programmers and that other
> programmers should seek different occupations? 

No, we should shape languages that are easy to learn.

> In any case, the above speakers will not accept the group of normal
> programmers as a premise; mostly because doing so will show C's
> imperfections when in the hands of imperfect programmers, *to* *a*
> *degree* that is largely caused by C---it could be less (which is
> why Cyclone is different, I should think). 

And why Ada is different.

> Those speaking in favor of C's "idiosyncrasies" like "int" deny the
> normal situation of imperfect programming... 

I don't know how "normal" it is to be programming in C and not
understand "int". I would hope it is not common at all!

> This is why I am skeptical of naming conventions that need twisted
> knowledge, like List : in out List.

I deny that this is "twisted"; that was the point of my response.

It makes perfect sense in English; we often use the same word to refer
to an item or a group. More commonly we use a plural form, but often
the plural form is the same as the singular. "List : Container" is no
better and no worse in English.

> My claim is that if Ada allows List : in out List, then there
> will be a growing number of programmers who "save time making
> up separate names" and routinely use T : T.

Yes! Then we will have more time for other things, like coming up
with good names for the other parameters.

You seem to be implying that this is a bad thing; what, exactly, is
the downside?

> To support this claim, I think I can point at another time saver:
> Anonymous "access" was introduced with Ada 2005. People like it. One
> reason is that it saves time making up pointer type names. (Viz.
> why, instead of declaring pointer types, not just add Foo* and &Bar
> like we are used to? Of course, I meant "X : access Foo;" and
> "Bar'Unchecked_Access"? Easy. Saves time.)

'Unchecked_Access is _not_ the same as as 'Access. Introducing bogus
arguments is not a good arguing tactic.

What is your point here? You seem to be implying that anonymous access
types are bad, but you don't say so. I disagree that they are bad.

> IMO, the effect of naming conventions is first and foremost an
> effect on human Ada programmers, caused by human programmers.
> The language definition will influence naming conventions,
> but this is accidental.

Yes, no one has said otherwise.

In this case, the fact that the language design has a single namespace
for objects and types leads to the need for a convention to
distinguish the two.

I argue for a simple mechanical convention; append _type to type
names.

Others argue for a complex time-consuming convention; come up with
different names.

Others also argue that types and objects should have names that differ
by more than a suffix for other reasons. Several attempts have been
made to explain those other reasons; as I understand it, they all come
down to this:

    Names should convey as much information as possible, thus they
    should be domain-specific whenever possible. Thus the natural
    names for objects and types are different in many situations.

To which the reply is:

    When the domain is very general, very general names are
    appropriate, and the natural object and type names are the same.
    Then _Type (or some similar noise) is necessary.

One could then suggest a relaxed convention:

    Append _Type if the type name is very general, use a
    domain-specific name otherwise.

I never seriously considered the latter; it involves deciding whether
a name is "very general", which is even harder than coming up with
different names. It's far easier to just use _Type.

Also, I prefer writing reusable code, which tends to be
domain-independent. If I'm working on robots, and I need a vector math
package to compute the robot positions, I don't call it
robot_position_vectors, I call it vectors. And it's generic in the
floating point type, which is just named Real_Type, not Meters,
or Radians, or Positions.

Concrete objects in the robot code are call Pos_Joint_n, Pos_Tool,
etc. Parameters to subprograms tend to have more generic names.

-- 
-- Stephe

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

[Vincent Marciante]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:u639mop0u.fsf@stephe-leake.org...
> "Vincent Marciante" <vmarciante@decilog.com> writes:
>
>> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
>> news:uskcsne3h.fsf@stephe-leake.org...
>>> "Vincent Marciante" <vmarciante@decilog.com> writes:
>>>
>>>> "Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message
>>>> news:u1vkdrert.fsf@stephe-leake.org...
>>>>> This is illegal:
>>>>>
>>>>>    procedure (List : in list);
>>>>>
>>>>> So we have to add noise to either the object or the type, to keep the
>>>>> compiler happy. That's all there is to it.
>>>>
>>>> That is not necessary:
>>>>
>>>> package sdgfkjasf is -- or whayever
>>>>
>>>>    type List is ...
>>>>
>>>>    procedure jsdfks (List : sdgfkjasf.List);
>>>>
>>>>    ...
>>>
>>> That's the first time I've seen that suggestion.
>>
>> Or maybe you forgot!
>
> Always possible.
>
>> The following is part of a old discusion to which you contributed:
>
> <snip>
>
> I don't see your point; that old discussion does _not_ propose using
> <package>.<type> to resolve the ambiguity.

My point was to show that my mentioning using
<package>.<type> to resolve ambiguity nicely
in my first message was actually not the first
time that it was mentioned (ever if not explicitely)
in c.l.a.  I probably expected that seeing that
simple example would be enough to cause a mental
"click" regarding some benifits of that construction.

No big deal, as long as there may now be at least
one less "_Type" writer. ;)

(Note that I wrote alittle more in one of your
other messages in the thread regarding original
Ada rationale.)


Vinny



>
> -- 
> -- Stephe 

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

[Vincent Marciante]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:u3a4pqrcz.fsf@stephe-leake.org...
> Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> writes:
>
>> On 11/7/09 6:49 AM, Stephen Leake wrote:
>>
>>> One reason to use "_Type" is precisely _because_ it means "Ada type";
>>> there's no need to   wonder about what it means.
>>
>> But the language meaning of "type" does not help with
>> the mentioned Message_Type_Type?
>> If I stubbornly follow your conventions as I understand them,
>> I'd have to write
>>
>>   procedure Something (Message_Type : in Message_Type_Type);
>> or
>>   procedure Something (Message_Type : in Message_Types.Message_Type);
>>
>> wouldn't I?
>
> Yes. This is the only special case, and usually I just stubbornly
> follow the convention. You get used to it.
>
> Another choice is to use Message_Label instead;
>
>   procedure Something (Message_Label : in Message_Label_Type);
>
>>> In another post, someone said Eiffel required<>  around types; is that
>>> not true?
>>
>> I mentioned Dylan where you would write string : <string>;
>
> Ah, sorry for the confusion.
>
>>
>> In Eiffel, and in hypothetical 2-namespace-Ada you write STring:
>> STring, if you want to. The visual difference is none. Is the
>> difference in meaning perfectly clear in the body lines following
>> the declaration?
>
> No, there are times when either an object or a type could be used, in
> attributes. Which is probably why Ada has a single namespace.
>
>>>>> Yes, this is an example of name overloading. Overloading, like any
>>>>> good thing, can be abused.
>>>>
>>>> Assuming separate namespaces for objects and types,
>>>> I can imagine programmers who find "string : STRING"
>>>> very clever.  Or just a good match for some twisted programming
>>>> trick.  Why make cleverness, or the appearance thereof,
>>>> easy to achieve?
>>>
>>> Good programmers will just find it natural; why introduce twisted
>>> programmers into this?
>>
>> OK, I thought that the design of a general purpose programming
>> language, together with the naming conventions surrounding it,
>> should be manageable by a general public of programmers, not just
>> "programmers who find this natural" =:def "good programmers".
>> Some good programmers, in fact language makers,
>> have made String : String impossible.
>
> Yes, for good reasons.
>
>> Supposedly, then, they did not deem String : String a natural thing,
>> even though they were good programmers.
>
> That's a stretch! Avoiding actual ambiguities is a better reason. But
> I don't presume to read their minds. It would be interesting to read
> some rationale on this; I don't think there is any in the Ada Language
> Manual.

What I gathered was that the original chief language
designer constructed the language rules with a goal
of trying to drive/impose the necessity of "good"
program architecture and trying to prevent/discourage
"bad" program architecture and I think that the following
was one of the things that was to be promoted:

- separating (having in different packages) the declaration
of types (abstract data types) and object of the type.

I think that having two namespaces would have made
having both in the same declarative region easier
but that would only really come up for the type
and only one object (or as a yucky "workaround")
an array of them) declared together.  Clearly, whenever
there are two objects of the type, the simple name
of one of them _must_ be different than the name of
the type unless they are in different declarative
regions.  I think that separate object and type
namespaces would simply have been redundant.

Also, I showed that the "parameter of subprogram
declaration" case (which was the old example that
I brought up in an earlier message) is easily and
elegantly dealt with by the sjkdf.type_name construct
So, that there is really no need for two namespaces
but there also is really is no need for any overall
naming convention either!

As to why there is "File_Type" in Text_IO instead
of various Sub(File:Text_IO.File) declarations, I'd
for a couple of reasons) say it was just a "mistake"
due to expediency.  My reasons are:
(1) The big text_IO package was not part of the original
language, it was added (relatively quickly?) in order
to reduce the amount of generic instantiations that
would be required to do simple io. (2) The original
chief designer afterward acknowlegded/commented that
he thought that even having text_io depend on the
predefined "integer" was a mistake.

With all of that I am not trying to be be "diffinative"
in any way, I'm just putting out what I remember and
(though about) from earily on at the start of my use
of Ada.

I hope that at least some of what I wrote is at all
useful (and that none of it is inacurate!)


Vinny

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

[Stephen Leake]

"Vincent Marciante" <vmarciante@decilog.com> writes:

>>>> That's the first time I've seen that suggestion.
>>>
>>> Or maybe you forgot!
>>
>> Always possible.
>>
>>> The following is part of a old discusion to which you contributed:
>>
>> <snip>
>>
>> I don't see your point; that old discussion does _not_ propose using
>> <package>.<type> to resolve the ambiguity.
>
> My point was to show that my mentioning using
> <package>.<type> to resolve ambiguity nicely
> in my first message was actually not the first
> time that it was mentioned (ever if not explicitely)
> in c.l.a.  

I still don't get it. If it was not mentioned explicitly, how was it
mentioned? If I had seen that suggestion before, I might be using it
now.

> No big deal, as long as there may now be at least
> one less "_Type" writer. ;)

Not likely, after 15 years of habit forming.

-- 
-- Stephe

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

[Stephen Leake]

"Vincent Marciante" <vmarciante@decilog.com> writes:

>>> Supposedly, then, they did not deem String : String a natural thing,
>>> even though they were good programmers.
>>
>> That's a stretch! Avoiding actual ambiguities is a better reason. But
>> I don't presume to read their minds. It would be interesting to read
>> some rationale on this; I don't think there is any in the Ada Language
>> Manual.
>
> What I gathered was that the original chief language
> designer constructed the language rules with a goal
> of trying to drive/impose the necessity of "good"
> program architecture and trying to prevent/discourage
> "bad" program architecture and I think that the following
> was one of the things that was to be promoted:
>
> - separating (having in different packages) the declaration
> of types (abstract data types) and object of the type.

Maybe, but we are also talking about subprogram parameters, which are in
the same package.

And there are certainly valid use cases for local types, especially
subtypes.

> I think that having two namespaces would have made
> having both in the same declarative region easier

Not much, it just would have avoided _Type.

> but that would only really come up for the type
> and only one object (or as a yucky "workaround")
> an array of them) declared together.  Clearly, whenever
> there are two objects of the type, the simple name
> of one of them _must_ be different than the name of
> the type unless they are in different declarative
> regions.  

Again, not true for subprogram parameters; there are many (one per
subprogram) with the same name. I guess the subprogram parameter list
can be thought of as a separate declarative region; I'm not sure it is
formally.

> Also, I showed that the "parameter of subprogram
> declaration" case (which was the old example that
> I brought up in an earlier message) is easily and
> elegantly dealt with by the sjkdf.type_name construct

Yes.

> So, that there is really no need for two namespaces but there also
> is really is no need for any overall naming convention either!

No, there is still a need for a convention; people need to know how to
react to the compiler error message. You are proposing that the
convention be "add enough of the full name of the type to
disambiguate". Which is also the convention for resolving other name
ambiguities (rather than changing one).

-- 
-- Stephe

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

[Vincent Marciante]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:uaayu24yf.fsf@stephe-leake.org...
> "Vincent Marciante" <vmarciante@decilog.com> writes:
>
>>>>> That's the first time I've seen that suggestion.
>>>>
>>>> Or maybe you forgot!
>>>
>>> Always possible.
>>>
>>>> The following is part of a old discusion to which you contributed:
>>>
>>> <snip>
>>>
>>> I don't see your point; that old discussion does _not_ propose using
>>> <package>.<type> to resolve the ambiguity.
>>
>> My point was to show that my mentioning using
>> <package>.<type> to resolve ambiguity nicely
>> in my first message was actually not the first
>> time that it was mentioned (ever if not explicitely)
>> in c.l.a.
>
> I still don't get it. If it was not mentioned explicitly, how was it
> mentioned? If I had seen that suggestion before, I might be using it
> now.
>> No big deal, as long as there may now be at least
>> one less "_Type" writer. ;)
>
> Not likely, after 15 years of habit forming.

I just reread all of the old thread and see
exactly what was previously discussed.
How about lets just leave it at this:

Ada _does_ allow one to name an object with the
same simple name as that of its type as long as
the type is in a different declarative region.
Also, (obviously only) one subprogram parameter
can also share the same simple name as its type
as long as the type name is fully qualified.
Given that, adding noise characters to a type
name or a object name is not scrictly necessary.

Vinny

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

[Hibou57 (Yannick Duchêne)]

Do not remember if it was already previously suggested in this
discussion : it appears to me a naming convention for tagged types is
helpful to better understand an implementation. I already use _Class
and _Class_Access (although I would enjoy a shorter one for this one)
postfix for class-wide types and class-wide access, now I feel the
_Type postfix is not enough. Types and tagged types should be
distinguishable at first sight as well.

By the way, I was thinking this may be an idea to think about in
future days, to add to the now widely used syntax colorization, a step
forward : semantic colorization (may be with font variants).

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

[Georg Bauhaus]

On 12/30/09 12:27 AM, Hibou57 (Yannick Duch�ne) wrote:
> Do not remember if it was already previously suggested in this
> discussion : it appears to me a naming convention for tagged types is
> helpful to better understand an implementation. I already use _Class
> and _Class_Access (although I would enjoy a shorter one for this one)
> postfix for class-wide types and class-wide access, now I feel the
> _Type postfix is not enough. Types and tagged types should be
> distinguishable at first sight as well.

Are you certain that the removal of abstraction---by adding
type properties to object names---will help when trying to
understand a program?  It might rather give the quick reader
the impression of understanding the program from just a look
at the objects' names, I think.  An illusion, most likely,
for how could you make meaningful changes to a program by
knowing just little things like "this is a tagged type" from
looking at object names?

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

[Hibou57 (Yannick Duchêne)]

On 30 déc, 10:31, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:
> Are you certain that the removal of abstraction---by adding
> type properties to object names---will help when trying to
> understand a program?  It might rather give the quick reader
> the impression of understanding the program from just a look
> at the objects' names, I think.  An illusion, most likely,
> for how could you make meaningful changes to a program by
> knowing just little things like "this is a tagged type" from
> looking at object names?

You are right in some way, as this idea came into my mind while I was
modifying an application which is not mine. So indeed, there may be
some reason to assert this is simply too much quickly said, on a time
where one feel lost and simply do not know enough.

OTOH, there must be a obvious starting point to this understanding,
and this suggested idea may be one after all. Or else (or moreover), I
feel a bit like tagged types and other types does not belong to the
same kind of abstraction any way.

Nevertheless, I will think about the potential Illusion you pointed to
me.

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

[Marco]

On Dec 30, 2:31 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:
> > and _Class_Access (although I would enjoy a shorter one for this one)
> > postfix for class-wide types and class-wide access, now I feel the
> > _Type postfix is not enough. Types and tagged types should be
> > distinguishable at first sight as well.
>
> Are you certain that the removal of abstraction---by adding
> type properties to object names---will help when trying to
> understand a program?

I agree - for code to be reusable in the long run it should have some
level of abstraction - specification distinguished from implementation
including public types

  adding awful "Hungarian" names does not help Ada

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

[Hibou57 (Yannick Duchêne)]

On 30 déc 2009, 10:31, Georg Bauhaus <rm-
host.bauh...@maps.futureapps.de> wrote:
> Are you certain that the removal of abstraction---by adding
> type properties to object names---will help when trying to
> understand a program?  It might rather give the quick reader
> the impression of understanding the program from just a look
> at the objects' names, I think.  An illusion, most likely,
> for how could you make meaningful changes to a program by
> knowing just little things like "this is a tagged type" from
> looking at object names?

On 31 déc 2009, 14:48, Marco <prenom_no...@yahoo.com> wrote:
> I agree - for code to be reusable in the long run it should have some
> level of abstraction - specification distinguished from implementation
> including public types
>
>   adding awful "Hungarian" names does not help Ada

You are both right, this would be too much, just because the added
value is below the level of the added noise.

Doing too much does not help to a convention to gain audiance.

Just a comment “ tout-de-même ” :

On 31 déc 2009, 14:48, Marco <prenom_no...@yahoo.com> wrote:
>   adding awful "Hungarian" names does not help Ada
This never had anything to deal with the Hungarian notation, which
recalls type information in instance names. This mostly has to deal
with the determination of a name which cleanly match and express the
role of an entity. Types does not play the same role as instances
does, and moreover (and the biggest point) as previously pointed,
there is in Ada, no separate name spaces for type names and instance
names.

As I'm there, here is the opportunity to introduce another usage
case : there is a another trick similar to the one of type-name
against instance-name which I oftenly encounter : a constant or a
variable whose most obvious name would be the same as a function,
which by the way, is in most of case used to initialize it. To have a
legal source is much more easy than to have a beautiful source, and
although — providing a function F exist — if I would like to name a
variable F which would be initialized with something returned from F,
using F_Value for the variable name or Get_F for the function name, in
the sole purpose to avoid a naming clash, ends up in a legal source,
but not a pretty-beautiful source.

Packaging and package name prefix may help here (coming with a name
space), but only when there are other good reasons to have this
package.

Well, if F is a variable, this can be declared, and later initialized
in a named block instead of from a function (although it seems less
clean to me). But what about when F is an initialized constant ? I do
not know any nice way (not an Ada flaw, as legal Ada source allows to
do what is to be done as specified, just a matter of aesthetic — which
in turns influence the feeling of readability).

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

[Hibou57 (Yannick Duchêne)]

Just to add an example of the latter : a package specification
provides a function which returns Who_Know_What, this function is
naturally named Who_Know_What, and in the implementation this
Who_Know_What should is to be a top level variable.

... Who_Know_What_Value ? Who_Know_What_Memory ?
Who_Know_What_Buffer ? Who_Know_What_Status ?

There is in most of cases, no natural choice (not to be confused with
an obvious choice, I'm not expect this kind of choice could be
obvious), this is why I do not like to face this choice

At least in this example, I will know only the variable name is to be
tricked, not the function name in the interface. In an implementation,
both may be tricked.

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

[Hibou57 (Yannick Duchêne)]

On 31 déc 2009, 14:48, Marco <prenom_no...@yahoo.com> wrote:
> I agree - for code to be reusable in the long run it should have some
> level of abstraction - specification distinguished from implementation
> including public types
>
>   adding awful "Hungarian" names does not help Ada

More words about it (completing my previous words)

An example came into my mind yesterday and makes me think about this
topic here : a example with a usage of the _Access prefix. An example
to show how the use of _Access may not simply be Hungarian notation,
is when this convention is applied to a type whose purpose is to have
the semantic of an access type, that is, when a copy of an entity of
this type used somewhere, will access the same thing as what we would
get with the original, even if some modification was done via the
original later after the copy was done.

This may be implemented as record, an integer, a standard access type.
Hungarian notation would mark it as being a record, an integer or a
standard access type. _Access does not.

This may looks like Hungarian notation, while it is actually not.