Naming of Tagged Types and Associated Packages

Naming of Tagged Types and Associated Packages

[taashlo]

In the _Ada 95 Quality and Style_ guidelines, section 3.2.4 "Naming of
Tagged Types and Associated Packages", there are two instantions.  One
integrates the use of object-oriented features.  The other highlights
the use of object-oriented features.  Could somebody please give a 
summary of the strengths and weaknesses of each?  And maybe an example
of where one convention would be more appropriate than the other?

Thanks,

Tad Ashlock <taashlo@sandia.gov>

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

taashlo@sandia.SPAMFREE.gov writes:

> In the _Ada 95 Quality and Style_ guidelines, section 3.2.4 "Naming of
> Tagged Types and Associated Packages", there are two instantions.  One
> integrates the use of object-oriented features.  The other highlights
> the use of object-oriented features.  Could somebody please give a 
> summary of the strengths and weaknesses of each?  And maybe an example
> of where one convention would be more appropriate than the other?

Here are a few ideas:

1) Name the package using the plural of the (tagged on non-tagged) type
it exports:

package Bank_Accounts is 

   type Bank_Account is tagged limited private;
...
end Bank_Accounts;


If you export more the one ADT, then the package name should conver the
theme of the types; it may be just the plural of the root of a type
hierarchy:

package Computer_Equipment is

   type Root_Equipment is tagged private;

   type CD_ROM is new Root_Equipment with private;

   type Floppy_Disk is new Root_Equipment with private;

   type Hard_Drive is new Root_Equipment with private;
...
end Computer_Equipment;


2) Name the type with a noun phrase:

type Root_Equipment is tagged private;

type Bank_Account is tagged private;

type File_Type is private;

3) If you have a type hierarchy, and you want to put the derived types
in different package, then put the types in child packages of the package
that declares the root type.  Name the child packages using the
adjective used to name the derived type:

package Bank_Accounts.Checking is

   type Checking_Account is new Bank_Account with private;
...


package Bank_Accounts.Savings is

   type Savings_Account is new Bank_Account with private;
...


And whatever you do, please do NOT name a type "Object" or "Instance".
This is a sure sign of confusion about the difference between a module
and a type, which are orthogonal language features in Ada.

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

>And whatever you do, please do NOT name a type "Object" or "Instance".
>This is a sure sign of confusion about the difference between a module
>and a type, which are orthogonal language features in Ada.
>
Well, since I was the first one to publish that notation (I do not claim to
be the first one who thought of it), let me follow up.

We are talking about classes here, and a class is an encapsulation of a data
type together with operations. In that sense, a type is certainly not a
class, since it addresses only the data-type part of a class.

Rather, a class is a certain way of using a package, to declare a type and
associated operations (methods), and nothing else. Of course, there are
other ways of using packages: packages, as well as types and nearly any
other feature of the language, are building blocks that allow you to create
various paradigms depending on the way you put them together.

However, if you agree that such a package corresponds to what is called a
class in OO languages, then it makes sense to name the package, not the
type, after the entity you want to represent. Now the package may declare
some utility types in addition to the "main" type; it makes sense to have
some notation to distinguish this main type. "Instance" or "Object" look
nice in a declaration like:
    My_Account: Bank_Account.Instance;

but this is not the main point. The really important point is to use the
same name for the main type of every  "class package", because it allows you
to have a uniform convention, whether you're using a declared package or an
instantiation of a generic. And remember that generic are very important,
since they provide multiple inheritance (or to be more politically correct:
because they fulfill the needs that are fulfilled by multiple inheritance in
other languages ;-)

A full discussion of these issues can be found in the paper "a naming
convention for classes in Ada 9X" which appeared in Ada Letters by the end
of 94 (sorry, I don't have the exact reference at hand).

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Sat, 25 Jul 1998, Jean-Pierre Rosen wrote:
> >And whatever you do, please do NOT name a type "Object" or "Instance".
> >This is a sure sign of confusion about the difference between a module
> >and a type, which are orthogonal language features in Ada.
> >
> Well, since I was the first one to publish that notation (I do not claim to
> be the first one who thought of it), let me follow up.
> 
> We are talking about classes here, and a class is an encapsulation of a data
> type together with operations. In that sense, a type is certainly not a
> class, since it addresses only the data-type part of a class.
> 
> Rather, a class is a certain way of using a package, to declare a type and
> associated operations (methods), and nothing else. Of course, there are
> other ways of using packages: packages, as well as types and nearly any
> other feature of the language, are building blocks that allow you to create
> various paradigms depending on the way you put them together.
> 
> However, if you agree that such a package corresponds to what is called a
> class in OO languages, then it makes sense to name the package, not the
> type, after the entity you want to represent. Now the package may declare
> some utility types in addition to the "main" type; it makes sense to have
> some notation to distinguish this main type. "Instance" or "Object" look
> nice in a declaration like:
>     My_Account: Bank_Account.Instance;

I could follow your reasoning up to this point, but I think that it is a
mistake to name a *type* something like Instance or Object, since an
instance is more like a variable. If you want to adhere to the 
module = class style of OOP, where there is one main type in the package, 
then the Modula-3 convention of using the name "T" for the type, mentioned 
here previously by Fergus Henderson, seems more appropriate. The name
Object or Instance should only appear on the left hand side of the
declaration. Of course, this assumes that you are an orthodox OOer who 
doesn't coencapsulate types...

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> The name
> Object or Instance should only appear on the left hand side of the
> declaration.

An excellent point.  To call a type "Object" is thoroughly confusing,
because an object is the thing that is an instance of the type.

There is a long tradition in the Ada community of using the expression
  O : T;

as shorthand when discussing programming issues.  I can't remember
anyone using the expression
  The_O : P.O;

as "short"hand.

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> >And whatever you do, please do NOT name a type "Object" or "Instance".
> >This is a sure sign of confusion about the difference between a module
> >and a type, which are orthogonal language features in Ada.
> >
> Well, since I was the first one to publish that notation (I do not claim to
> be the first one who thought of it), let me follow up.

Jean-Pierre: I loved your other article in ACM, "What Orientation Should
Ada Objects Take," but "didn't care for" the one you mention above, in
Ada Letters.
 
> We are talking about classes here, and a class is an encapsulation of a data
> type together with operations. In that sense, a type is certainly not a
> class, since it addresses only the data-type part of a class.

This is wrong.  The defination of a type has _always_ been "data +
operations."  The term "class" to designate a type is an unfortunate
mistake make by the designers of Simula.
 
> Rather, a class is a certain way of using a package, to declare a type and
> associated operations (methods), and nothing else. 

I prefer to refer to such a package as "a package that exports an
abstract data type" or just "an ADT package."  To refer to such a
package as a "class" is incorrect, because a package is a module, not a
type.

The use of the convention "P.Instance" to refer to the "real" type name
is very misguided, because it's as if you're trying to make a package
into a type, which it is not.

If the language designers had wanted module and type to be the same,
then they would have designed the language that way, and you wouldn't
need to say "type Instance is ..." at all.  

You might not like it, especially since this is probably perceived as
idiosyncratic by programmers who have used other object-oriented
languages (in which module and type are the same), but that's just the
way it is.  No coding convention is going to change this.

> However, if you agree that such a package corresponds to what is called a
> class in OO languages, then it makes sense to name the package, not the
> type, after the entity you want to represent. 

No, I do most certainly do NOT agree that a package is equivalent to a
class in other languages.  A class is a type, and we already have types
in Ada.  All a package does in Ada is to demarcate which operations of
the type are primitive.

The "real" name of the type is the identifier used in the type
declaration, never the name of the enclosing package.

> Now the package may declare
> some utility types in addition to the "main" type; it makes sense to have
> some notation to distinguish this main type. "Instance" or "Object" look
> nice in a declaration like:
>     My_Account: Bank_Account.Instance;

You may think it looks nice, but I read this and think "Je crois qu'elle
est laide."  Why not just
   My_Account: Bank_Account;

You know, the way the language designers intended?
 
> but this is not the main point. The really important point is to use the
> same name for the main type of every  "class package", because it allows you
> to have a uniform convention

I don't understand what you mean.  We've been calling files File_Type
for almost 20 years, and so far no one has complained.

> A full discussion of these issues can be found in the paper "a naming
> convention for classes in Ada 9X" which appeared in Ada Letters by the end
> of 94 (sorry, I don't have the exact reference at hand).

We obviously have philosophical differences about the nature of a type.
Oh, well.  I'll be in Paris in September: perhaps we can meet at a cafe
to discuss it more over "une pression"!

Re: Naming of Tagged Types and Associated Packages

[nabbasi]

offcourse a type is defined as set of values and set of operations.

I find it very hard in Ada to visualize an tagged object. but I can 
easily visulaize a class object in Java or C++ becuase the class construct 
makes it easy for me to do that.

when I used Ada, I use it as an object-based (as opposed to object-oriented)
langauge, which is what Ada was originally designed as, I do not use Ada for 
its OO features. I like Ada as a procedural/object based, and for that it 
is great. plus I think all the OO/inhertence stuff is way overrated any way.

abstraction, data hiding, sepration of interfaces and implementaions, strong
typing, generics, good exception, good build-in tasking model, and all 
that good stuff is good enough for me. If I want to do heavy/pure
OO stuff, I would not use Ada, just becuase I am not used to the OO 
ways of Ada, it just too different from all the other OO languages 
out there (different in how its OO features are reprsented offcourse,
 the semactics are the same, but language representation (lexical
structure) is very important I think becuase it affect how one thinks
 and visualize things), and in that the class structure is more natural than
tagged records + procedures that takes paramters or returns paramters
of types of that record.

my 2 cents.

Nasser

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

nabbasi@earthlink.net writes:

> offcourse a type is defined as set of values and set of operations.

Yes.

> I find it very hard in Ada to visualize an tagged object. but I can 
> easily visulaize a class object in Java or C++ becuase the class construct 
> makes it easy for me to do that.

I don't understand your problem:

   type T is tagged private;

is exactly equivalent to

   class T {...

in C++.


If the features of a type aren't obvious from reading the text of an Ada
program, then something is probably wrong with the program, not the
language itself.

> when I used Ada, I use it as an object-based (as opposed to object-oriented)
> langauge, which is what Ada was originally designed as, I do not use Ada for 
> its OO features. I like Ada as a procedural/object based, and for that it 
> is great. plus I think all the OO/inhertence stuff is way overrated
> any way.

Pete Wegner has done a lot of damage, I'm afraid.  His classification of
Ada 83 as object-based is incorrect.  Ada 83 is properly classified as a
type-based language (his term was "class-based," but I want to stick to
Ada terminology).

The addition of tagged types in Ada 95 is good, but it doesn't change
implementation techniques that much from Ada 83, because you should
already be using type-based abstractions where that makes sense.  (I
give some advice for knowing when to use a package vs when to use a type
in the design patterns archives at the ACM website.  Search for
"singleton".).

I agree, by the way, that inheritence as a re-use mechanism is way
overrated.  All it does is increase coupling, and make (deep)
hierarchies too sensitive to changes in the classes near the root.  Ada
provides composition mechanisms that don't require inheritence.

This means that if you're building deep inheritance hierarchies in Ada
95 ("deep" defined as more than 2 or 3 levels), then you're probably
doing something wrong.  Any normal system is going to require changes as
it is built, so you'll have the compile-the-universe problem every time
there's a change.

> abstraction, data hiding, sepration of interfaces and implementaions, strong
> typing, generics, good exception, good build-in tasking model, and all 
> that good stuff is good enough for me. If I want to do heavy/pure
> OO stuff, I would not use Ada, just becuase I am not used to the OO 
> ways of Ada, it just too different from all the other OO languages 
> out there (different in how its OO features are reprsented offcourse,
>  the semactics are the same, but language representation (lexical
> structure) is very important I think becuase it affect how one thinks
>  and visualize things), and in that the class structure is more natural than
> tagged records + procedures that takes paramters or returns paramters
> of types of that record.

How you do it in Ada 95 is not much different from how you do it in Ada
83.  If you think Ada 95 is "too different" from other oo languages,
then you must think the same think about Ada 83, right?

The Ada way has some advantages, because I can say this:

   if O1 = O2 then ...;

instead of the klunky

   if O1.Is_Equal (O2) the ...;

Re: Naming of Tagged Types and Associated Packages

[Robert Dewar]

Nasser said

<<abstraction, data hiding, sepration of interfaces and implementaions, strong
typing, generics, good exception, good build-in tasking model, and all
that good stuff is good enough for me. If I want to do heavy/pure
OO stuff, I would not use Ada, just becuase I am not used to the OO
ways of Ada, it just too different from all the other OO languages
out there (different in how its OO features are reprsented offcourse,
 the semactics are the same, but language representation (lexical
structure) is very important I think becuase it affect how one thinks
 and visualize things), and in that the class structure is more natural than
tagged records + procedures that takes paramters or returns paramters
of types of that record.
>>

Note that in the above, you note that you are not used to the OO ways of
Ada, and then go on to make some comments that really would only ve valid
if you *did* have the necessary familiarity. In fact once you know these
features well, and are "use" to them, you will find that (a) they are quite
natural to use, and (b) it is rather trivial to make the syntactic 
transition for cases where there is a direct correspondence. Of course
in the cases where there is NOT a direct correspondence (e.g. the built
in MI in C++, or the generalization of multiple arguments and return types
for dispatching in Ada), then the transition is of course harder.

Actually there are many "pure" OO abstractions for which the Ada approach,
which avoids the nasty binary operator problem in C++ is very much more
straightforward.

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

(In this discussion, we are discussing how to use classification in Ada;
whether classification  in itself is a good thing is a different issue; and
I don't think I can be accused of being an inheritance fan ;-)

Matthew Heaney a �crit dans le message ...
>"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
>
>> We are talking about classes here, and a class is an encapsulation of a
data
>> type together with operations. In that sense, a type is certainly not a
>> class, since it addresses only the data-type part of a class.
>
>This is wrong.  The defination of a type has _always_ been "data +
>operations."  The term "class" to designate a type is an unfortunate
>mistake make by the designers of Simula.
The *type* definition by itself only defines the data. It is the fact that
some operations are defined in the same *package specification* as the type
that makes them bound to the type. Yes, a package is an encapsulation
mechanism; it is the encapsulation that transforms a type + some operations
in a "class".

>The use of the convention "P.Instance" to refer to the "real" type name
>is very misguided, because it's as if you're trying to make a package
>into a type, which it is not.
In this case, the package is the "class".

>> Now the package may declare
>> some utility types in addition to the "main" type; it makes sense to have
>> some notation to distinguish this main type. "Instance" or "Object" look
>> nice in a declaration like:
>>     My_Account: Bank_Account.Instance;
>
>You may think it looks nice, but I read this and think "Je crois qu'elle
>est laide."  Why not just
>   My_Account: Bank_Account;

This is a very important issue in naming, which is much more general than
even this discussion.
Should a type name be descriptive of what the *type* is, or should it be
descriptive of what the *variables* are ?
In other terms, when you read:
    A : T;
do you read it as "A is of type T" or as "A is a T" ?
In the second case, my notation would directly read "My_Account is an
instance of Bank_Account". Other people may read it differently.
However, If I personnaly prefer naming related to variables rather than
type, it is because of a general principle that the client should be
favoured against the server. In this case, a type is defined once, and used
very often. I therefore prefer the name which is more descriptive in the
general case. But this certainly a matter of opinions.

>> but this is not the main point. The really important point is to use the
>> same name for the main type of every  "class package", because it allows
you
>> to have a uniform convention
>
>I don't understand what you mean.  We've been calling files File_Type
>for almost 20 years, and so far no one has complained.

Then, you miss the real issue. Actually, I wrote a book some times ago (in
French, and I still don't have a publisher for the english translation,
anybody's listening? ;-), and I stumbled into the problem of a consistent
notation for generics. That was the main triggering reason for that
notation. Since you didn't seem to keep you backlog of Ada Letters, let me
summarize the issue.

Assume (your notation):
package Bank_Accounts is
    type Bank_Account is tagged...
   -- operations ....
end Bank_Account;

Assume that some bank accounts are "privileged" in some sense. You want a
generic to allow this on any bank_account:
generic
    with old_account is new Bank_Account with private;
package Privileged_Account is
   type ??? is new old_Account with private;
   --- other operations
end Privileged_Account;

The trouble is that when you instantiate the generic, you can choose the
name of the new package, but not the names of what is declared inside, and
especially the type. I you want the type name to carry the useful
information, the type name should change with each instantiation! With my
notation, the package name carries the useful information, and therefore the
same convention can be used for packages obtained by generic instantiations
and for regular packages.

>We obviously have philosophical differences about the nature of a type.
>Oh, well.  I'll be in Paris in September: perhaps we can meet at a cafe
>to discuss it more over "une pression"!
I'd be glad to. Just drop me a note when you know when you are there.

--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> The *type* definition by itself only defines the data. It is the fact that
> some operations are defined in the same *package specification* as the type
> that makes them bound to the type. Yes, a package is an encapsulation
> mechanism; it is the encapsulation that transforms a type + some operations
> in a "class".

When I think of "type," I don't just think of the statement 

   type T is ...;

I think of "type" as 

1) The name of the type, introduced by a type declaration of the form
"type T is ..."

2) The primitive operations of the type, which are the subprograms that
take the type named T as a parameter, and are declared in the same
package as the type declaration.

I do not equate "type" with the statement "type T is ...", and that
seems to be where you and I part ways.  A type is more than that, as it
comprises a name, some data, and some operations.  You call this thing a
"class," but I prefer to stick to Ada terminology.  

The Ada statement "type T is ..." tells me the name (and ultimately the
representation), but that is not equivalent to a "type"; it isn't enough
to be a type.
 
> >The use of the convention "P.Instance" to refer to the "real" type name
> >is very misguided, because it's as if you're trying to make a package
> >into a type, which it is not.
> In this case, the package is the "class".

I don't make a distinction between "type" and "class."  The Ada term is
for type is "type," and the term "class" means "family of types."

Again, let's go back to the RM:

Text_IO.File_Type 
  is not called File.Instance

Ada.Strings.Unbounded.Unbounded_String
  is not called Ada.Strings.Unbounded_String.Instance

Ada.Tags.Tag 
  is not called Ada.Tag.Instance

System.Storage_Elements.Storage_Element 
  is not called System.Storage_Element.Instance


Why don't Ada programmers like to do what's in the RM?



> >> Now the package may declare
> >> some utility types in addition to the "main" type; it makes sense to have
> >> some notation to distinguish this main type. "Instance" or "Object" look
> >> nice in a declaration like:
> >>     My_Account: Bank_Account.Instance;
> >
> >You may think it looks nice, but I read this and think "Je crois qu'elle
> >est laide."  Why not just
> >   My_Account: Bank_Account;
> 
> This is a very important issue in naming, which is much more general than
> even this discussion.
> Should a type name be descriptive of what the *type* is, or should it be
> descriptive of what the *variables* are ?
> In other terms, when you read:
>     A : T;
> do you read it as "A is of type T" or as "A is a T" ?

Both.  Because there is no difference.

> In the second case, my notation would directly read "My_Account is an
> instance of Bank_Account". 

When I see the declaration

   My_Account : Bank_Account;

I think "My_Account is an instance of Bank_Account."  How else would you
interpret it?


> Other people may read it differently.

I have to believe you that there are "other people" who read it
differently, but it seems pretty obvious to me that the declaration

   O : T;

means "Object O is an instance of type T."

If these people are that confused about the nature of a declaration,
then I'm not sure a naming convention is going to be enough to end their
confusion.

> Then, you miss the real issue. Actually, I wrote a book some times ago (in
> French, and I still don't have a publisher for the english translation,
> anybody's listening? ;-), and I stumbled into the problem of a consistent
> notation for generics. That was the main triggering reason for that
> notation. Since you didn't seem to keep you backlog of Ada Letters, let me
> summarize the issue.
> 
> Assume (your notation):
> package Bank_Accounts is
>     type Bank_Account is tagged...
>    -- operations ....
> end Bank_Account;
> 
> Assume that some bank accounts are "privileged" in some sense. You want a
> generic to allow this on any bank_account:
> generic
>     with old_account is new Bank_Account with private;
> package Privileged_Account is
>    type ??? is new old_Account with private;
>    --- other operations
> end Privileged_Account;

What's wrong with the convention

generic
   type Account_Type is new Bank_Account with private;
package Privileged_Mixin is

   type Privileged_Account is new Account_Type with private;
...
end Privileged_Mixin;


> The trouble is that when you instantiate the generic, you can choose the
> name of the new package, but not the names of what is declared inside, and
> especially the type. I you want the type name to carry the useful
> information, the type name should change with each instantiation! With my
> notation, the package name carries the useful information, and therefore the
> same convention can be used for packages obtained by generic instantiations
> and for regular packages.

I suppose you could just do another local type derivation, or declare a
local subtype.  This isn't a big issue for me.  I'm happy enough to be
able to determine the characteristics of the type once, at point of
instantiation, rather than being reminded every object declaration.

> >We obviously have philosophical differences about the nature of a type.
> >Oh, well.  I'll be in Paris in September: perhaps we can meet at a cafe
> >to discuss it more over "une pression"!
> I'd be glad to. Just drop me a note when you know when you are there.

Oui, d'accord!

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Matthew Heaney a �crit dans le message ...
>"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
>[...]
>When I think of "type," I don't just think of the statement
>
>   type T is ...;
>
>I think of "type" as
>
>1) The name of the type, introduced by a type declaration of the form
>"type T is ..."
>
>2) The primitive operations of the type, which are the subprograms that
>take the type named T as a parameter, and are declared in the same
>package as the type declaration.
Agreed, but this happens ONLY if the type and associated "methods"
(primitive operations) are declared in the same package. Therefore, it's the
package that turns a "type" into a "class".

>I don't make a distinction between "type" and "class."  The Ada term is
>for type is "type," and the term "class" means "family of types."
In this discussion, I take "class" with the conventional meaning of the OOP
world. The nice thing with Ada is that its building blocks approach allows
you to build various paradigms, and we are talking here about one such
special paradigm. Whether naming it "OOP" and using "class" is a good idea
is another issue...

>Again, let's go back to the RM:
>
>Text_IO.File_Type
>  is not called File.Instance
>
>Ada.Strings.Unbounded.Unbounded_String
>  is not called Ada.Strings.Unbounded_String.Instance
>
>Ada.Tags.Tag
>  is not called Ada.Tag.Instance
>
>System.Storage_Elements.Storage_Element
>  is not called System.Storage_Element.Instance

I responded to that in an other message...

>What's wrong with the convention
>
>generic
>   type Account_Type is new Bank_Account with private;
>package Privileged_Mixin is
>
>   type Privileged_Account is new Account_Type with private;
>...
>end Privileged_Mixin;

When you instantiate the package, all types will be named
"Privileged_Account". Agreed, in this example it is not too bad, but think
for example of a package that adds persistency to any tagged type:
generic
   type Origin is tagged private;
package Persistence is
   type Persistent is new Origin with private;
   ...
end Persistence;

Then all types to which you add persistency will be called simply
"Persistent". Now, you'll tell me that it won't be a problem, since you'll
use full notation. But how will you name the package ? "Persistent_Account"
? That would give Persistent_Account.Persistent. Not really pretty.
And what if you have a bank account which is both Persistent and Privileged
? Depending on the order of instantiation, you would end up with either
Persistent_Privileged_Bank_Account.Persistent or
Persistent_Privileged_Bank_Account.Privileged_Account. This would give a
special importance to the one which is instantiated last...

Once again, if you don't like the name "instance", take something else, but
the idea is to have a single, *neutral* name for the main type, in order to
have a consistant and uniform notation.

>I suppose you could just do another local type derivation, or declare a
>local subtype.
This was my idea when I first studied the issue, and my paper discusses why
it does not work. Please have a look at it. If you don't have an archive of
Ada Letters, just drop me a mail telling your preferred format, and I'll be
happy to send it to you (if others in this newsgroup also want a copy, they
are also welcome :-)

--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <6pk3jh$gpm$2@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:

> This was my idea when I first studied the issue, and my paper discusses why
> it does not work. Please have a look at it. If you don't have an archive of
> Ada Letters, just drop me a mail telling your preferred format, and I'll be
> happy to send it to you (if others in this newsgroup also want a copy, they
> are also welcome :-)

You could just post it here. Or does that break an agreement with Ada Letters?

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<6pkoir$sh6$1@nnrp1.dejanews.com>...
>In article <6pk3jh$gpm$2@platane.wanadoo.fr>,
>  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
>> This was my idea when I first studied the issue, and my paper discusses
why
>> it does not work. Please have a look at it. If you don't have an archive
of
>> Ada Letters, just drop me a mail telling your preferred format, and I'll
be
>> happy to send it to you (if others in this newsgroup also want a copy,
they
>> are also welcome :-)
>
>You could just post it here. Or does that break an agreement with Ada
Letters?
>

OK, it is available as http://perso.wanadoo.fr/adalog/naming9x.zip
It is a zipped file that contains naming9x.doc (word6 format) and
naming9x.ps (PostScript)
I don't think there is any copyright issue, AFAIK Ada-Letters allows free
reprints of papers.
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <6pmrkd$5v9$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> OK, it is available as http://perso.wanadoo.fr/adalog/naming9x.zip
> It is a zipped file that contains naming9x.doc (word6 format) and
> naming9x.ps (PostScript)

27K is mighty small for a Zip file :-).

It looks like a large part of the original rationale assumes the need for
using generics to provide MI-like facilities to specific child classes of a
class.

Folks on c.l.a who don't like "Instance" on account of it confusing the issue
of what's an object and what's a type, ought to really dislike this:

"By the same token, the declaration of the main type is always followed by
the declaration of a subtype for the corresponding class wide type; this
subtype is always named "class"."

So we're using a package to implement a class. But it contains a type named
"Class". But "Class" isn't actually full type. Its a subtype declared using
the declaration of "Instance", which isn't actually an Instance in the
OO-sense but a type. %-(

I'm not entirely satisfied with this approach. To me it breaks the fundamental
principle that identifiers should be named to describe their metaobject.
Instance may be used to create instances, but it is *not* itself an instance
(in the OO sense). But neither is it a class in and of itself. It takes the
operations in the package and the type to make up a class.

But its a whole lot easier to be a critic than a creator. I have yet to think
up or see anything better.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<6pnfkv$qkg$1@nnrp1.dejanews.com>...
>In article <6pmrkd$5v9$1@platane.wanadoo.fr>,
>  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>> OK, it is available as http://perso.wanadoo.fr/adalog/naming9x.zip
>> It is a zipped file that contains naming9x.doc (word6 format) and
>> naming9x.ps (PostScript)
>
>27K is mighty small for a Zip file :-).
>
>It looks like a large part of the original rationale assumes the need for
>using generics to provide MI-like facilities to specific child classes of a
>class.
>
>Folks on c.l.a who don't like "Instance" on account of it confusing the
issue
>of what's an object and what's a type, ought to really dislike this:
>
>"By the same token, the declaration of the main type is always followed by
>the declaration of a subtype for the corresponding class wide type; this
>subtype is always named "class"."
>
>So we're using a package to implement a class. But it contains a type named
>"Class". But "Class" isn't actually full type. Its a subtype declared using
>the declaration of "Instance", which isn't actually an Instance in the
>OO-sense but a type. %-(
I appreciate the humour, but it is technically inaccurate. Class *is* a full
type, because Instance'class is not the same *type* as Instance. It is even
called a "class-wide type", to justify calling it "Class"... OK, I use a
subtype to replace a renaming.
Note that without this subtype, the class wide type would be called
Instance'class, which even I find ugly ;-)

>I'm not entirely satisfied with this approach. To me it breaks the
fundamental
>principle that identifiers should be named to describe their metaobject.
>Instance may be used to create instances, but it is *not* itself an
instance
>(in the OO sense). But neither is it a class in and of itself. It takes the
>operations in the package and the type to make up a class.


Let me explain once again my position (and I understand perfectly why others
may not agree on this).
The only use of a type is to declare variables, constants, and formal
parameters (these three categories are globally called "objects" in the RM,
but I didn't dare using that term in the context of this discussion...).
In a client-server model, I tend to favour the client against the server; in
this context, it means that I choose a name that maximizes readability of
the *variable declaration*, not of the *type declaration*.
Given this, I consider that:
   An_Account  : Bank_Account.Instance;  -- may contain only an instance of
Bank_Account
  All_Accounts : Bank_Account.Class := F; -- may contain any value in the
class of Bank_Account
makes sense...
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <6pp9k8$77j$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> In a client-server model, I tend to favour the client against the server; in
> this context, it means that I choose a name that maximizes readability of
> the *variable declaration*, not of the *type declaration*.

I guess that's where you start to loose me. My philosophy is that *both*
sides need to be readable. After all, its just as likely (if not more) that
the server will break as the client. But again, this is the best overall
approach I have found so far. (Plus, it seems to be somewhat of a standard
now).

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<6pq1mo$qm$1@nnrp1.dejanews.com>...
>In article <6pp9k8$77j$1@platane.wanadoo.fr>,
>  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>> In a client-server model, I tend to favour the client against the server;
in
>> this context, it means that I choose a name that maximizes readability of
>> the *variable declaration*, not of the *type declaration*.
>
>I guess that's where you start to loose me. My philosophy is that *both*
>sides need to be readable. After all, its just as likely (if not more) that
>the server will break as the client. But again, this is the best overall
>approach I have found so far. (Plus, it seems to be somewhat of a standard
>now).
>
Of course, if you can have it both ways, it's better. I'm talking when a
trade-off is necessary, and normally a package is used more often than it is
maintained (hopefully :-). Thus my preference for the most common usage.
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[Robert I. Eachus]

In article <6pi71p$n90$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

 > The trouble is that when you instantiate the generic, you can choose the
 > name of the new package, but not the names of what is declared inside, and
 > especially the type. I you want the type name to carry the useful
 > information, the type name should change with each instantiation! With my
 > notation, the package name carries the useful information, and therefore the
 > same convention can be used for packages obtained by generic instantiations
 > and for regular packages.

   Ah, but I always find myself doing the following:

   package Foobar is new Foo(....);
   type Something_Meaningful is new Foobar.Object_Type with null;
   -- and possibly
   function My_Op(Param: Something_Meaningful) return Integer;

   So both the use clause issue, and the meaningful name issue go away.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

eachus@spectre.mitre.org (Robert I. Eachus) writes:

>    Ah, but I always find myself doing the following:
> 
>    package Foobar is new Foo(....);
>    type Something_Meaningful is new Foobar.Object_Type with null;
>    -- and possibly
>    function My_Op(Param: Something_Meaningful) return Integer;
> 
>    So both the use clause issue, and the meaningful name issue go away.


Ahhh, the voice of reason in a chaotic world!  

Listen to the DRs guys!  They know what they're doing!

Thank you, thank you, thank you, thank you, thank you, ...

Matt

P.S. Did I say thank you, Bob?

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Robert I. Eachus a �crit dans le message ...
>In article <6pi71p$n90$1@platane.wanadoo.fr> "Jean-Pierre Rosen"
<rosen.adalog@wanadoo.fr> writes:
>
> > The trouble is that when you instantiate the generic, you can choose the
> > name of the new package, but not the names of what is declared inside,
and
> > especially the type. I you want the type name to carry the useful
> > information, the type name should change with each instantiation! With
my
> > notation, the package name carries the useful information, and therefore
the
> > same convention can be used for packages obtained by generic
instantiations
> > and for regular packages.
>
>   Ah, but I always find myself doing the following:
>
>   package Foobar is new Foo(....);
>   type Something_Meaningful is new Foobar.Object_Type with null;
>   -- and possibly
>   function My_Op(Param: Something_Meaningful) return Integer;
>
>   So both the use clause issue, and the meaningful name issue go away.
I discussed the drawbacks of this approach in my paper
(http://perso.wanadoo.fr/adalog/naming9x.zip, now includes the ppt version
thanks Ted Dennison).
Basically: forces you to use empty extension aggregate. If the package
declares other stuff (like secondary types) you must reexport it manually.

Re: Naming of Tagged Types and Associated Packages

[Robert I. Eachus]

  I said:

 > Ah, but I always find myself doing the following:...
 >
 > So both the use clause issue, and the meaningful name issue go away.

In article <6ppc3q$8ju$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

 >  I discussed the drawbacks of this approach in my paper
 > (http://perso.wanadoo.fr/adalog/naming9x.zip, now includes the ppt version
 >  thanks Ted Dennison).
 > Basically: forces you to use empty extension aggregate. If the package
 > declares other stuff (like secondary types) you must reexport it manually.

  This is where we will have to leave it.  I don't find adding "with
null" offensive, and I usually do need to access secondary types, but
the only sane way to do it is with a qualified names because there may
be several types of that name (often the same one) in the derivation stack.

  A VERY simplified example:

  with Ada.Finalization;
  package People is 

    type Person is tagged private;

    function Name(Who: in Person) return String;
    procedure Set_Name(Who: in out Person; Name: in String);
    function Address(Who: in Person) return String;
    function Set_Address(Who: in out Person; Address: in String);
    ...

  private

    package Add_Name is new Unbounded_String_Component(
           Ada.Finalization.Controlled);
    package Add_Address is new Unbounded_String_Component(
           Add_Name.Record_Type);
    type Person is new Add_Address.Record_Type with null;

    pragma Inline(Name, Set_Name, Address, Set_Address);

  end People;

  Now in the body I'll have to write things like:

    function Name(Who: in Person) return String is
    begin return Add_Name.Get(Who); end Name;

  I can't use a renaming as body, because Get takes a classwide
parameter so I don't get driven crazy by adding conversions.  Yes, you
can use dispatching, but when you have twenty or so instantiations, it
gets seriously confusing.

  why go to all the "trouble" required to build object classes like
this?  Because the operations required to display an object with
dynamic updating and other niceties comes with the component packages.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Very interesting, I think we are progressing...

Robert I. Eachus a �crit dans le message ...
>  A VERY simplified example:
>
>  with Ada.Finalization;
>  package People is
>
>    type Person is tagged private;
>
>    function Name(Who: in Person) return String;
>    procedure Set_Name(Who: in out Person; Name: in String);
>    function Address(Who: in Person) return String;
>    function Set_Address(Who: in out Person; Address: in String);
>    ...
>
>  private
>
>    package Add_Name is new Unbounded_String_Component(
>           Ada.Finalization.Controlled);
>    package Add_Address is new Unbounded_String_Component(
>           Add_Name.Record_Type);
>    type Person is new Add_Address.Record_Type with null;
>
>    pragma Inline(Name, Set_Name, Address, Set_Address);
>
>  end People;
>
>  Now in the body I'll have to write things like:
>
>    function Name(Who: in Person) return String is
>    begin return Add_Name.Get(Who); end Name;


Your example is excellent, because you declare a *private* tagged type, and
export its operations explicitely. But

pragma Disclaimer (on);
I do think, and often claim, that one of the big advantages of Ada over
other OO languages is that you can use inheritance at *implementation* level
without using it at specification level; or (like here) have hidden
inheritances, that allow you to break the transitive dependence. I have
therefore much sympathy for the way the example is written; however, we are
discussing naming of classes in the general case here, in the context of
"traditionnal" OO style.
pragma Disclaimer (off);

if you want to *visibly* add a facet, then it wouldn't work so easily (once
again, look at the example in the paper).

Why would you want to add visibly a facet ? Because this way, if you add new
operations to a facet, they are immediately inherited by all users. If you
instantiate privately, you'll have to add new "interface" routines to all
packages. Granted, this is better from the point of view of encapsulation,
but not from the point of view of flexibility. And the "pure OOP" approach
is most effective in cases where flexibility is considered more important
than encapsulation (but this is another debate).
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[Robert I. Eachus]

In article <6ps2ne$hko$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

 > I do think, and often claim, that one of the big advantages of Ada over
 > other OO languages is that you can use inheritance at *implementation* level
 > without using it at specification level; or (like here) have hidden
 > inheritances, that allow you to break the transitive dependence. I have
 > therefore much sympathy for the way the example is written; however, we are
 > discussing naming of classes in the general case here, in the context of
 > "traditionnal" OO style...

 > Why would you want to add visibly a facet ? Because this way, if you add new
 > operations to a facet, they are immediately inherited by all users. If you
 > instantiate privately, you'll have to add new "interface" routines to all
 > packages. Granted, this is better from the point of view of encapsulation,
 > but not from the point of view of flexibility. And the "pure OOP" approach
 > is most effective in cases where flexibility is considered more important
 > than encapsulation (but this is another debate).

   That's why I said we have to leave it here.  My style of developing
in Ada 95 results in very few "open" types other than those where the
descendent types are defined by generic instantiation.  Therefore, I
am the only person who sees inside the encapsulation.  Jean-Pierre has
stated several times that he uses a more open style, and explicitly
designs expecting much more work to be done by the user of the type
rather than the creator.

   Due to this difference in style, we will always reach different
conclusions about how naming should be done.  Maybe I can talk
Jean-Pierre into my way of designing, but from experience, that is a
very slow process.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Robert I. Eachus a �crit:
> 
>    That's why I said we have to leave it here.  My style of developing
> in Ada 95 results in very few "open" types other than those where the
> descendent types are defined by generic instantiation.  Therefore, I
> am the only person who sees inside the encapsulation.  Jean-Pierre has
> stated several times that he uses a more open style, and explicitly
> designs expecting much more work to be done by the user of the type
> rather than the creator.
??? I think I said in a previous message that the goal was to favour the
*user* of a type against  the *designer*...

>    Due to this difference in style, we will always reach different
> conclusions about how naming should be done.  Maybe I can talk
> Jean-Pierre into my way of designing, but from experience, that is a
> very slow process.
Of course, we are discussing style here, so it's a matter of taste. 
As I mentionned before, I agree with you (and generally use) a "closed"
style, and I try to keep inheritance as hidden as possible. However the
purpose of this thread was to discuss a notation for those who want pure
OO programming, and pure OO means a lot of visibility! Quoting Booch
(from memory):
"There is a very real tension between encapsulation and inheritence. To
a large degree, inheritance exposes the secrets of the inherited class,
sometimes including their inside view".

-- 
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> writes:

> Of course, we are discussing style here, so it's a matter of taste. 
> As I mentionned before, I agree with you (and generally use) a "closed"
> style, and I try to keep inheritance as hidden as possible. However the
> purpose of this thread was to discuss a notation for those who want pure
> OO programming, and pure OO means a lot of visibility! Quoting Booch
> (from memory):
> "There is a very real tension between encapsulation and inheritence. To
> a large degree, inheritance exposes the secrets of the inherited class,
> sometimes including their inside view".

A great quote that hints at the pitfalls of inheritance from a systems
point of view.  Visibility implies coupling, and coupling is bad.  Very,
very bad.

An even better source is your own ACM paper "What orientation should Ada
objects take?"  It bravely challenges current dogma about inheritance as
a mechanism for the composition of abstractions.  (Thank you - I was
cheering when I read it!)

Everyone should also read "The Architecture of Complexity," by Herb
Simon.  It appears as a chapter in his book Sciences of the Artificial.

Yes, the question might be "What naming convention do I use to effect
pure OO programming in Ada 95?"  But maybe we should be asking ourselves
instead, "What is the simplest way to construct software systems using
Ada 95?"

If the system is modifiable and extensible, with minimal coupling among
the parts, then should we really care whether a "pure OO" approach was
used?  Who even knows what "pure OO" means?

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Matthew Heaney a �crit dans le message ...
>Yes, the question might be "What naming convention do I use to effect
>pure OO programming in Ada 95?"  But maybe we should be asking ourselves
>instead, "What is the simplest way to construct software systems using
>Ada 95?"
Obviously a different, but interesting one.
>
>If the system is modifiable and extensible, with minimal coupling among
>the parts, then should we really care whether a "pure OO" approach was
>used?  Who even knows what "pure OO" means?
FWIW, here is the criteria that I use when I decide to use an inheritance
based mechanism.
-1) I need a family of types that are different enough for not considering
them as "variants" of a single type (in which case a discriminated type
would be prefered), but still have enough commonalities for applying common
operations to all of them, and
-2) I need to maintain heterogenous data structures of these types, and I
need to apply the operations regardless of the specific type.

A typical example (not very original) is widgets: a menu cannot be
considered a variant of a window or a button, however there is a "paint"
operation that applies to all, and I may have to keep a list of displayed
widgets to which I want to apply Paint. Another example is for making
persistent objects, where I maintain a list of caches for various object
types, and where I want to flush all caches to the data base when the
program terminates.

Re: Naming of Tagged Types and Associated Packages

[Robert I. Eachus]

In article <6q8utd$54o$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

 > FWIW, here is the criteria that I use when I decide to use an inheritance
 > based mechanism.
 > -1) I need a family of types that are different enough for not considering
 > them as "variants" of a single type (in which case a discriminated type
 > would be prefered), but still have enough commonalities for applying common
 > operations to all of them, and
 > -2) I need to maintain heterogenous data structures of these types, and I
 > need to apply the operations regardless of the specific type.

   I was going to say I add a third group, but it isn't really that,
it is more of a closure.  I mostly to use inheritance and mixins as a
decomposition technique.  In Ada 95, I can keep details of structures
like lists and queues separate from the contents.  This is why I lean
towards closed coding and naming that is really targetted towards the
user in the package spec, and the author elsewhere.

   But that is the BIG difference between the way inheritance is used
in other languages and the way I believe it should be used in Ada.
Used right in Ada 95, inheritance reduces coupling and increases
cohesion.  I can have a list of target records where the code for list
abstraction is totally decoupled from the declaration and operations
of the target abstraction and vice-versa.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <m367gl943o.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:

> The "real" name of the type is the identifier used in the type
> declaration, never the name of the enclosing package.

No, its the package name PLUS the identifier used in the type declaration.
Unless, of course you throw use clauses everywhere in your code. If you do
that then it doesn't matter much what convention you use, I won't be able to
read your code.

We have preliminarliy standardized on the Package_Name.Instance notation here.
I'm not sure I like it either, but I have yet to see a suggestion that is
better when full name notation is used. The other suggestions I have seen here
so far either redundantly name the type and the package, or encode the fact
that it is a type in the type name or a package in the package name (duh).


> You may think it looks nice, but I read this and think "Je crois qu'elle
> est laide."  Why not just
>    My_Account: Bank_Account;
>

Because that won't work. What you are really proposing is something like:

My_Account: Bank_Account_Package.Bank_Account;

...which really reads worse and types much longer than:

My_Account : Bank_Account.Instance;

> You know, the way the language designers intended?

Be careful. While this may be a nifty convention for ending discussions about
the U.S. constitution, the Ada language designers aren't yet dead. In fact,
they are still around and reading c.l.a. In my experience they have a rather
annoying habit of piping in and disagreeing with me when I was sure they'd
agree. :-)

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Stephen Leake]

dennison@telepath.com writes:

> In article <m367gl943o.fsf@mheaney.ni.net>,
>   Matthew Heaney <matthew_heaney@acm.org> wrote:
> 
> > The "real" name of the type is the identifier used in the type
> > declaration, never the name of the enclosing package.
> 
> No, its the package name PLUS the identifier used in the type declaration.
> Unless, of course you throw use clauses everywhere in your code. If you do
> that then it doesn't matter much what convention you use, I won't be able to
> read your code.
> 
> We have preliminarliy standardized on the Package_Name.Instance notation here.
> I'm not sure I like it either, but I have yet to see a suggestion that is
> better when full name notation is used. The other suggestions I have seen here
> so far either redundantly name the type and the package, or encode the fact
> that it is a type in the type name or a package in the package name (duh).

How about Package_Name.Instance_Type? That makes clear the "type" vs
"object" question.

-- Stephe

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <uogub2jq5.fsf@gsfc.nasa.gov>,
  Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> dennison@telepath.com writes:
>
> > We have preliminarliy standardized on the Package_Name.Instance notation
here.
> > I'm not sure I like it either, but I have yet to see a suggestion that is
> > better when full name notation is used. The other suggestions I have seen
here
> > so far either redundantly name the type and the package, or encode the fact
> > that it is a type in the type name or a package in the package name (duh).
>
> How about Package_Name.Instance_Type? That makes clear the "type" vs
> "object" question.

Again, you have encoded the fact that it is a type in the type's name. I don't
need that information, and it leads to really stupid looking things like
"Command_Type_Type".

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Mon, 27 Jul 1998 dennison@telepath.com wrote:
>   Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> > dennison@telepath.com writes:
> >
> > > We have preliminarliy standardized on the Package_Name.Instance notation
> here.
> > > I'm not sure I like it either, but I have yet to see a suggestion that is
> > > better when full name notation is used. The other suggestions I have seen
> here
> > > so far either redundantly name the type and the package, or encode the fact
> > > that it is a type in the type name or a package in the package name (duh).
> >
> > How about Package_Name.Instance_Type? That makes clear the "type" vs
> > "object" question.
> 
> Again, you have encoded the fact that it is a type in the type's name. I don't
> need that information, and it leads to really stupid looking things like
> "Command_Type_Type".

The first part of your assertion, that you don't *need* this information,
is certainly correct. If you can't stand redundancy, you should dump Ada,
and embrace either C++, which enables you to do away with many explicit
generic instantiations, or a language with type-inference, like ML,
Haskell, or Mercury, which lets you do away with almost all explicit
typing and still gives you static type checking. :-) :-) 

The second part of your assertion, that it leads to stupid things like 
Command_Type_Type, is completely false. I use the _Type convention, and
and a similar convention in C, I've never had this problem arise. If you 
don't like that convention, fine, but don't just make up problems which 
don't really happen .

If you only have one main type per package, why not give it a single
letter name like T or I (for Instance, yuk!)?

-- Brian

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <Pine.BSF.3.96.980727153418.13706B-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> The second part of your assertion, that it leads to stupid things like
> Command_Type_Type, is completely false. I use the _Type convention, and
> and a similar convention in C, I've never had this problem arise. If you
> don't like that convention, fine, but don't just make up problems which
> don't really happen .

Hmmm. I've seen it happen all over the place, in my code and others. Maybe it
hasn't happened to *you*, but that doesn't mean it doesn't happen. Heck, if
that logic works, I assert that death does not exist. After all, it hasn't
ever happened to me. Ha Ha! Now I'll live forever. Suffer, mortal fools! :-)

If you *like* the "Hungarian notation"-like conventions that are common in C
work, that's fine. But you aren't going to be able to convince me its a good
thing for Ada any more than I can convince you its not. In the meantime, we
horribly bore everyone else. It's best to just not go there.

> If you only have one main type per package, why not give it a single
> letter name like T or I (for Instance, yuk!)?

Actually, that's a very valid point (I may be misreading you here, but heck,
I'm going with it). "Instance" is so undescriptive, it might as well be "I".
That's part of the reason I'm not entirely satisfied with the
Package_Name.Instance convention.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Tue, 28 Jul 1998 dennison@telepath.com wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > The second part of your assertion, that it leads to stupid things like
> > Command_Type_Type, is completely false. I use the _Type convention, and
> > and a similar convention in C, I've never had this problem arise. If you
> > don't like that convention, fine, but don't just make up problems which
> > don't really happen .
> 
> Hmmm. I've seen it happen all over the place, in my code and others. Maybe it
> hasn't happened to *you*, but that doesn't mean it doesn't happen. Heck, if
> that logic works, I assert that death does not exist. After all, it hasn't
> ever happened to me. Ha Ha! Now I'll live forever. Suffer, mortal fools! :-)

Good one! However, my point wasn't that you couldn't do it, just that
you'd have to be deliberately silly to do so (come on Ted, you really
couldn't think of a better name than Command_Type_Type?). It would
be like me using single letter names for everything, and then using the
ensuing confusion to argue that names without the "_Type" are hopelessly
confusing. Anyways, don't make up silly arguments against my preferred
naming convention, and I promise not to comment on it again, OK? ;-)

> > If you only have one main type per package, why not give it a single
> > letter name like T or I (for Instance, yuk!)?
> 
> Actually, that's a very valid point (I may be misreading you here, but heck,
> I'm going with it). "Instance" is so undescriptive, it might as well be "I".

You read me perfectly, though I'd prefer "T" to "I" as the name of the
main type, for the reasons being discussed elsewhere. Also, this  
convention is widely used by our cousins in the Modula-3 community, and
I'm told it is used in the Ada community too, ar least for explanation.
It also makes sense if you eschew use clauses, and name your packages with 
the "class" name, in a module = type style of OOP. 

My issue with this is that I often coencapsulate types, and sometimes
there is no main type in a package, though I suppose thats easy enough to 
fix by using T,U,V,W, ... or T1, T2, T3, ... 

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Tue, 28 Jul 1998, Brian Rogoff wrote:
> My issue with this is that I often coencapsulate types, and sometimes
> there is no main type in a package, though I suppose thats easy enough to 
> fix by using T,U,V,W, ... or T1, T2, T3, ... 

Oops, I forgot to put a string of ":-)" here!

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> On Tue, 28 Jul 1998, Brian Rogoff wrote:
> > My issue with this is that I often coencapsulate types, and sometimes
> > there is no main type in a package, though I suppose thats easy enough to 
> > fix by using T,U,V,W, ... or T1, T2, T3, ... 
> 
> Oops, I forgot to put a string of ":-)" here!

But you bring up a good point.  Frequently, there are types that are
cohesive enough that they really belong together in the same package.
An example is a data structure (say a stack or queue) and its associated
active iterator, connected by a factory method.

The problem is, if you name the stack type Instance, then what do you
name the iterator type?

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Wed, 29 Jul 1998, Matthew Heaney wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > On Tue, 28 Jul 1998, Brian Rogoff wrote:
> > > My issue with this is that I often coencapsulate types, and sometimes
> > > there is no main type in a package, though I suppose thats easy enough to 
> > > fix by using T,U,V,W, ... or T1, T2, T3, ... 
> > 
> > Oops, I forgot to put a string of ":-)" here!
> 
> But you bring up a good point.  Frequently, there are types that are
> cohesive enough that they really belong together in the same package.
> An example is a data structure (say a stack or queue) and its associated
> active iterator, connected by a factory method.

Thats one good example, and thats why the joking suggestion about
numbering the type names should have gotten a smiley. Another similar 
example is the "index" type of a random access collection. I find that 
violations of the one-main-type-per-package rule occur very frequently. 

What I have done in my own generic collection libraries, whose source you 
can peruse at http://www.best.com/~bpr/agl.html, is stick the iterators 
in child packages of the collection, so I suppose I could make the T 
convention work, if I wanted to.

-- Brian

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <Pine.BSF.3.96.980728084100.28778A-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> Good one! However, my point wasn't that you couldn't do it, just that
> you'd have to be deliberately silly to do so (come on Ted, you really
> couldn't think of a better name than Command_Type_Type?). It would

Its not something that is typically done just to be silly. In fact, the issue
comes up among other places on nearly every record that has an enumerated
variant.

A very typical example: I have a command that gets passed to a routine for
processing. The standard says it should be named Command_Type. It is
implemented with several "data" fields and an enumeration field specifing
what the actual command is (what "type" of command it is). The natural name
for that is Command_Type. Under the naming convetion, it becomes
Command_Type_Type.

Again, this isn't something that's deliberately done by me to be silly (lord
knows I do plenty of those). Its something that I have seen come up often in
*other*people's* code.

I've worked on a couple of programs where the lead engineer got the coding
standards written so that putting "_type" on the end of every type was
specifically *forbidden*. Usually derisive verbal abuse from fellow engineers
is enough to do the job, though. :-)

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dennison@telepath.com writes:

> A very typical example: I have a command that gets passed to a routine for
> processing. The standard says it should be named Command_Type. It is
> implemented with several "data" fields and an enumeration field specifing
> what the actual command is (what "type" of command it is). The natural name
> for that is Command_Type. Under the naming convetion, it becomes
> Command_Type_Type.

Although I don't use the _Type convention (it should be used only for
"static polymorphism," as it is in the RM), you can get around the
problem you describe by naming the type "Command_Kind."  This avoids any
potential ambiguity about whether it's a command or just a kind of
command.

> I've worked on a couple of programs where the lead engineer got the coding
> standards written so that putting "_type" on the end of every type was
> specifically *forbidden*.

Give that guy a medal for doing the smart thing.  The types in the RM
aren't named using _Type, so why do it that way in your code?

Re: Naming of Tagged Types and Associated Packages

[Chris Brand]

Matthew Heaney wrote:
> 
>  The types in the RM
> aren't named using _Type, so why do it that way in your code?

Except, of course, Ada.Text_IO.File_Type.

-- 
Chris
Stating my own opinions, not those of my company.

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Chris Brand <cbrand@west.raytheon.com> writes:

> Matthew Heaney wrote:
> > 
> >  The types in the RM
> > aren't named using _Type, so why do it that way in your code?
> 
> Except, of course, Ada.Text_IO.File_Type.

Good point.  The reason (I think - the DRs will correct me if I'm wrong)
for the the _Type convention for files has to do with "static
polymorphism." 

"Static polymorphism" you say?  Hmmm?   How can polymorphism - usually
associated with dynamic behavior - be static?

Suppose we named type Direct_IO.File_Type "Direct_File", and suppose we
named Sequential_IO.File_Type "Sequential_File".  I've argued for this
kind of thing in the past, but here's why it's a bad idea.

I need a sequential file type, so I instantiate generic package
Sequential_IO on my type, and then declare a bunch of instances:

package T_IO is new Sequential_IO (T);
use T_IO;

procedure Op1 is
   File : Sequential_File;
begin ...


procedure Op2 is 
   File : Sequential_File;
begin ...


procedure Op3 is
   File : Sequential_File;
begin ...


You get the idea.  Everywhere where I declare a file instance, the type
is named Sequential_File.

Now, suppose that as a build the software, or a requirement changes (not
unlikely), I realize that I need direct file access, not just sequential
access.  The means I have to do a new instantiation, and everywhere
where there's a Sequential_File, there's now needs to be a Direct_File.

If I'm lucky, the change might be in a single package body, and I can
use a search & replace to do the change.  But I might not be so lucky,
and I might accidently change other file instances that shouldn't be
changed.  If I'm really unlucky, then the name might be spread across
packages, and I have to change a bunch of code that causes a massive
recompile on the entire system.

You get the idea.  The best approach is the not have to do any editing
at all, and only change which file package is being instantiated.

So let's use a neutral name like "File_Type", so that that all I have to
do is make a single change - to change the instantiation from
Sequential_IO to Direct_IO.  All the file objects have the same type
name.  All the operations have the same signiture too, so no code needs
changed.

If I need to know the characteristics of a file instance (to determine
whether it's sequential or direct), then I don't need to be reminded of
this every time I declare an object.  All I need to do is state that
information once, at the point of instantiation of the generic file
package.

That is why the interfaces for Sequential_IO and Direct_IO are
identical.  It's sorta like deriving each file type from an abstract
root type.  Instead of refering to a class-wide type called
Root_File'Class and doing dynamic dispatching on primitive operations,
you refer to a "root type" called File_Type, and invoke primitive
operations statically.

I've written a data structures library that does this kind of thing.
No, I did not create a type hierarchy rooted at Root_Stack, with
different stacks deriving from Root_Stack.  No (public) tagged types or
inheritance were needed thank you very much.  I simply have different
kinds of stacks that are NOT part of a type hierarchy, but do have
identical interfaces.  Just like Sequential_IO and Direct_IO.

Because I want a client to be able to easily change the code if he
changes his mind about what kind of stack he needs (say, to go from a
bounded stack to a dynamic stack with a statically allocated heap), I
just named all the stack types Stack_Type.  (Brian Rogoff must be
smiling right now...)   Just like File_Type.

This does not mean, however, that you should name every type using the
_Type convention.  This is a big mistake, because then the convention
would loose its value as an indicator of static polymorphism.

For example, the active iterator for the Stack_Type is called
Stack_Iterator.  It's not just any Iterator_Type, it's an iterator for
stacks, so call it that.

This is exactly like file mode, which is not called Mode_Type.  It's
call File_Mode.  Because it's not just any mode type, it's a file mode,
so call they called it that.

All the conventions you need are right there in the RM.  You don't need
to do anything different from the RM, because the DRs already figured it
out.  So take their advice about how to program in Ada, and do as the RM
does.

So I'll say it again: naming types "Instance" is a bad idea, for no
other reason than that is not a convention that appears in the RM.
(There are other reasons it's not a good idea, but those have been
debated in other posts.)

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <m3vhogw00r.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:

> So let's use a neutral name like "File_Type", so that that all I have to
> do is make a single change - to change the instantiation from
> Sequential_IO to Direct_IO.  All the file objects have the same type
> name.  All the operations have the same signiture too, so no code needs
> changed.

I still whould have gone with "File" instead of "File_Type".
:-)

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dennison@telepath.com writes:

> I still whould have gone with "File" instead of "File_Type".
> :-)

I'm not sure why there's a smiley there, but in general, types should be
named using a two-part phrase.  That way you can name the object using a
shortened version of the type name, as in

Kind : Command_Kind;

File : File_Type;

Pool : Storage_Pool;

Speed : Speed_In_MPH;

etc.

If you name the type File, then you have to name the object The_File,
but the definate article just adds noise (not unlike the over-use of
_Type...) that your reader is going to mentally parse out anyway.

This was the style used by Booch way back when, but I find it a bit
old-fashioned nowadays.

As I mentioned in another post, a similar idiom applies to a type
hierarchy.  The root type of the hierarchy should be named with a
two-part phrase, for example Root_Stack or Bank_Account.

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <m3pvenww5v.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> dennison@telepath.com writes:
>
> > I still whould have gone with "File" instead of "File_Type".
> > :-)
>
> I'm not sure why there's a smiley there, but in general, types should be
> named using a two-part phrase.  That way you can name the object using a
> shortened version of the type name, as in

The smiley was there because this is clearly a matter of taste. The rule I
live by is that objects (including types) should be named as specific to the
role they serve as is reasonable. Couple that with full dot notation and name
clashes really are rather rare. For instance your declaration for file
becomes:

  File : Configuration_IO.File;

or better yet, something like:

  Configuration_File : Configuration_IO.File;

...but that's me.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Simon Wright]

Matthew Heaney <matthew_heaney@acm.org> writes:

> You get the idea.  Everywhere where I declare a file instance, the type
> is named Sequential_File.
> 
> Now, suppose that as a build the software, or a requirement changes (not
> unlikely), I realize that I need direct file access, not just sequential
> access.  The means I have to do a new instantiation, and everywhere
> where there's a Sequential_File, there's now needs to be a Direct_File.

So why not call them just File? (OK, you can't "use" with such gay
abandon, good thing too :-)

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Simon Wright <simon@pogner.demon.co.uk> writes:

> Matthew Heaney <matthew_heaney@acm.org> writes:
> 
> > You get the idea.  Everywhere where I declare a file instance, the type
> > is named Sequential_File.
> > 
> > Now, suppose that as a build the software, or a requirement changes (not
> > unlikely), I realize that I need direct file access, not just sequential
> > access.  The means I have to do a new instantiation, and everywhere
> > where there's a Sequential_File, there's now needs to be a Direct_File.
> 
> So why not call them just File? (OK, you can't "use" with such gay
> abandon, good thing too :-)

Because that's what I want to call the instance of the type: File.

In an Ada declaration, the object and the type can't have the same name.
If the object is called File, then the type has to be called something
else.  (Note that Eiffel doesn't have this "problem," because the object
and its type are in different namespaces.)

That's why I recommend using a two-word phrase to name types.  General
types like Integer don't have to follow this convention, because there's
no danger of an object ever being named Integer.

I gave reasons in the previous post why you should use the _Type
convention only for certain situations (as an indicator of "static
polymorphism").  To use that convention everywhere only adds noise that
your reader is going to have to mentally remove.

Someone responded by arguing that you could do this:

declare
   File : Configuration_IO.File;
begin

but I don't care for this because it has the same problem as
Jean-Pierre's Package_Name.Instance convention: it tries to elevate the
package name to the same status as a type name.

A package name is not a type name, because a package is not a type.  A
package is a namespace, and it exists only (more or less) to prevent
name clashes among identically named types.

Use expanded name notation ONLY when you have identically named types in
the same scope.  Please do not use expanded name notation to prevent a
name clash between object name and the type name.

You might argue that you could name the object, instead of the type,
using the long form:

declare
   Configuration_File : File;
begin

but this too is a mistake.  You only need to state the properties of the
object _once_, during its declaration.  When you use the long form for
the object, then you are adding noise everywhere the object is used,
which the reader is just going to mentally strip out anyway.

The idea is that you should say what you want to say by stating as
little information as possible.  This is the essence of abstraction.  If
the reader wants more information, then give him an easy path to find
it.

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <m37m0suor4.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Simon Wright <simon@pogner.demon.co.uk> writes:
>

> > So why not call them just File? (OK, you can't "use" with such gay
> > abandon, good thing too :-)
>
> Someone responded by arguing that you could do this:
>
> declare
>    File : Configuration_IO.File;
> begin
>
> but I don't care for this because it has the same problem as
> Jean-Pierre's Package_Name.Instance convention: it tries to elevate the
> package name to the same status as a type name.

No, its not the type name. But it is used as *part* of the type name. Think of
it as a family name. Just like "Romeo Montague" means "Romeo of the family
Montague", Configuration_IO.File means "File of the package Configuration_IO".

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dennison@telepath.com writes:

> No, its not the type name. But it is used as *part* of the type
> name. Think of it as a family name.  Just like "Romeo Montague" means
> "Romeo of the family Montague", Configuration_IO.File means "File of
> the package Configuration_IO".

"The" type name or just "part" of the type name, I don't see any
difference.

You're giving me a personal model is what a type name is.  Fair enough,
that's your model.  But I prefer to stick to the model in the RM.  And
in the RM, file types are all named File_Type.  There is a reason.

In a declaration, the object name and type name share a namespace.  I
think the intent was that object and type have different names.  And by
type "name" I mean without using expanded name notation.

I don't think the intent was to use expanded name notation to resolve
the namespace clash in an object declaration.  Expanded name notation
should be used only to qualify identically named types in the same
scope.

If the designers of the language had wanted you to name the object and
type the same, then they would have specified the language so that
object and type have different namespaces _automatically_.  (This is
indeed the choice Meyer made with Eiffel.)  So you could do this:

   File : File;

legally.  But the Ada designers didn't do that.

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <m3pveiju8i.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:

> You're giving me a personal model is what a type name is.  Fair enough,
> that's your model.  But I prefer to stick to the model in the RM.  And
> in the RM, file types are all named File_Type.  There is a reason.

Yeah. The reason was: that was the first application *ever* written in Ada,
and they didn't know any better. :-)

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Matthew Heaney a �crit dans le message ...
>A package name is not a type name, because a package is not a type.  A
>package is a namespace, and it exists only (more or less) to prevent
>name clashes among identically named types.
>
This is absolutely true from the point of view of  the *language
definition*.
However, you *use* it to form higher level abstractions. It then becomes
that higher level abstraction.
For example, a paint is just a chemical product with peculiar optical
properties, but when used in a certain way, it becomes the Joconde...

A package used in a certain way makes up a class (in classical OO mode).
When used otherwise, it may become something else, and I 100% agree that
different conventions might then be preferable.

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1213 bytes --]

On Tue, 4 Aug 1998, Jean-Pierre Rosen wrote:
> Matthew Heaney a écrit dans le message ...
> >A package name is not a type name, because a package is not a type.  A
> >package is a namespace, and it exists only (more or less) to prevent
> >name clashes among identically named types.
> >
> This is absolutely true from the point of view of  the *language
> definition*. However, you *use* it to form higher level abstractions.
> It then becomes that higher level abstraction.
> For example, a paint is just a chemical product with peculiar optical
> properties, but when used in a certain way, it becomes the Joconde...
> 
> A package used in a certain way makes up a class (in classical OO mode).
> When used otherwise, it may become something else, and I 100% agree that
> different conventions might then be preferable.

Just a small point, which I'm sure Jean-Pierre understands, a class, in 
classical OO mode, is neither a package, nor a type, but combines elements 
of both. I think its just as correct, maybe more :-), to say that a tagged
type used a certain way makes up a class. By "classical OO" here I mean 
Eiffel style OO in which every module is a type. 

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Matt Heaney wrote:

:In an Ada declaration, the object and the type can't have the same name.
:If the object is called File, then the type has to be called something
:else.  (Note that Eiffel doesn't have this "problem," because the object
:and its type are in different namespaces.)

I think it's not so much namespaces but the fact that the syntax allows 
you (and the compiler) to easily differentiate variables (entities in 
Eiffel parlance) from types.

Some examples..

1) Variable declarations:

       variable : TYPE

   The identifier to the left of the colon is recognised as a variable 
   and the one on the right as a type.

2) Variable instantiations:

      !TYPE!variable

   The identifier framed by exclamation marks is recognised as a type 
   and the one following as a variable.

3) Selective export:

      feature {TYPE}

   Any identifier enclosed in curly brackets is a type.

4) Constrained generic parameters:

      class GENERIC_TYPE [G -> TYPE]

   All constrained generic parameters are types.

etc.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Wed, 5 Aug 1998, Don Harrison wrote:
> Matt Heaney wrote:
> 
> :In an Ada declaration, the object and the type can't have the same name.
> :If the object is called File, then the type has to be called something
> :else.  (Note that Eiffel doesn't have this "problem," because the object
> :and its type are in different namespaces.)
> 
> I think it's not so much namespaces but the fact that the syntax allows 
> you (and the compiler) to easily differentiate variables (entities in 
> Eiffel parlance) from types.

Well, I hate to agree with my mortal enemy Matthew :-), but for this to be 
correct it would have to be the case that Ada syntax doesn't allow you to 
differentiate types and variables in the analogous Ada constructs. At
least for your examples, this is obviously not true. So Matthew's point 
stands, it is the separate namespaces, not the syntax, that allows you to 
use the same names for types and variables. I find that very ugly, but I'm 
sure if I used Eiffel long enough my abhorence would diminish.

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Brian Rogoff wrote (in com.lang.ada):

:On Wed, 5 Aug 1998, Don Harrison wrote:
:> Matt Heaney wrote:
:> 
:> :In an Ada declaration, the object and the type can't have the same name.
:> :If the object is called File, then the type has to be called something
:> :else.  (Note that Eiffel doesn't have this "problem," because the object
:> :and its type are in different namespaces.)
:> 
:> I think it's not so much namespaces but the fact that the syntax allows 
:> you (and the compiler) to easily differentiate variables (entities in 
:> Eiffel parlance) from types.
:
:Well, I hate to agree with my mortal enemy Matthew :-), 

It's easy to make a friend of an enemy when arguing with an even greater 
"enemy".  :)

:"but for this to be 
:correct it would have to be the case that Ada syntax doesn't allow you to 
:differentiate types and variables in the analogous Ada constructs. 

No. That's a necessary, but not sufficient, condition. It's also necessary 
that the compiler actually *uses* this semantic information to disambiguate. 
In the case of Eiffel, it does; in the case of Ada, it doesn't.

:at least for your examples, this is obviously not true. So Matthew's point 
:stands, it is the separate namespaces, not the syntax, that allows you to 
:use the same names for types and variables. 

Your inference is wrong due to a false assumption. 

:I find that very ugly, but I'm 
:sure if I used Eiffel long enough my abhorence would diminish.

If I continue to use Ada, my abhorence of having to (unecessarily) 
invent different names will remain. :)


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[doylep]

In article <Pine.BSF.3.96.980805092758.8504A-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> [...] that allows you to
> use the same names for types and variables. I find that very ugly, but I'm
> sure if I used Eiffel long enough my abhorence would diminish.

I think you would, for two reasons:

1. Nothing's stopping you from making yourself use different names for
everything.

2. It allows you to avoid contrivances by permitting things like this:

class CAR

feature
    steering_wheel : STEERING_WHEEL

end

What else are you going to call the steering wheel?  A
direction_control_device? I think any other name would be contrived.

 -PD

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond 
to this in c.l.e., as I remember several language wars starting from
c.l.ada/eiffel crossposting, and I just don't care for them. 

On Fri, 7 Aug 1998 doylep@ecf.toronto.edu wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > [...] that allows you to
> > use the same names for types and variables. I find that very ugly, but I'm
> > sure if I used Eiffel long enough my abhorence would diminish.

should be "abhorrence", sorry.

> 
> I think you would, for two reasons:

My main reason was that I'll get used to anything given time, including 
C++, Perl, pro-wrestling, Taco Bell, ...

> 1. Nothing's stopping you from making yourself use different names for
> everything.

True, but I can't stop other programmers from doing it, and I suspect from 
these postings that this may be a common practice in Eiffel. Overall, I 
think this is a fairly minor nit to pick, but then we wouldn't be
programmers if we didn't like to argue over minor nits, would we?

> 2. It allows you to avoid contrivances by permitting things like this:
> 
> class CAR
> 
> feature
>     steering_wheel : STEERING_WHEEL
> 
> end
> 
> What else are you going to call the steering wheel?  A
> direction_control_device? I think any other name would be contrived.

Call the steering wheel Steering_Wheel, and call the type something like 
Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names
and variable names to be lexically distinguished, so the EuLisp/Dylan
convention, which would be to name it something like <SteeringWheel>,
would be my choice if I could do it all myself, but I don't think the
_Type convention is bad at all, and its used widely in my Ada reference
of choice (Ada as a Second Language).

If you want to talk about having to create contrived names, be careful, 
Eiffel doesn't have overloading, which is far worse IMO. Apparently the 
Sather designers agreed, when they decided to "fix" Eiffel, they added 
overloading. Other languages, like OCaml, do away with most of the need 
to name types altogether, so the antiredundantists should consider such 
languages before disparaging the Ada way in deference to Eiffel way.

pragma Rant(On);

The truth is I don't think I'll use Eiffel again, because I don't think 
its a very good language design. I think OO is overrated, and languages
that try to enforce OO as the *only* programming tool are not for me. I
like Eiffel's assertion mechanisms (though I'm not sure they belong in the
language or would be better left as a tool) but I think its type system is 
hopelessly broken, it *requires* whole-program analysis due to covariance;
bye-bye separate compilation! 

OTOH, despite the fact that Ada has numerous annoying flaws and
misfeatures, I find the overall language design quite sound. It 
supports the OO style well, but doesn't enforce it, and allows you 
not to use it at all if it isn't what you want. 

Obviously, people are free to have different opinions, and I wouldn't want
to start another Eiffel/Ada flamefest, so I generally avoid posting my
opinion on the Eiffel ng. 

pragma Rant(Off);

-- Brian
 

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> The truth is I don't think I'll use Eiffel again, because I don't think 
> its a very good language design. I think OO is overrated, and languages
> that try to enforce OO as the *only* programming tool are not for me.

You sometimes hear Ada refered to as "a 70's language."  I sometimes
think of Eiffel as "an 80's language," since it forces one to program
using a "pure" object-oriented paradigm.  What's so great about "pure"
object-oriented programming, anyway?

Not having done any programming in Eiffel, I'm not going to comment on
the design of that language, but I agree that object-oriented
programming is only one tool among many that a programmer should have at
his disposal.

The OO hype left over from the 80's hasn't quite subsided, but the tide
is turning.  People are finally beginning to realize that using (public)
inheritence to compose abstractions creates too many dependencies, which
can stymie the growth of a large system in development.

Indeed, the debates about the "proper" taxonomy for an inheritence tree
are redolent of the debates we had in the 70's about what the "proper"
decomposition of functions should be.  This is ironic, since the
object-oriented paradigm was intended to silence those debates!

Creating deep (public) inheritence hierarchies, though typical in "pure
OO" languages, is definately not a technique that should be used in
Ada95 or C++, where objects have value semantics.  Another thread on
this list has alluded to the better way, using "closed" abstractions
that use inheritence as a private, implementation mechanism.

Re: Naming of Tagged Types and Associated Packages

[doylep]

In article <Pine.BSF.3.96.980807163858.838A-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>
> Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond
> to this in c.l.e., as I remember several language wars starting from
> c.l.ada/eiffel crossposting, and I just don't care for them.

Yes, that's the same reason I am usually too afraid to venture into c.l.a. 
:-)

> On Fri, 7 Aug 1998 doylep@ecf.toronto.edu wrote:
>
> > 1. Nothing's stopping you from making yourself use different names for
> > everything.
>
> True, but I can't stop other programmers from doing it

Good point.

> > 2. It allows you to avoid contrivances by permitting things like this:
> >
> > class CAR
> >
> > feature
> >     steering_wheel : STEERING_WHEEL
> >
> > end
> >
> > What else are you going to call the steering wheel?  A
> > direction_control_device? I think any other name would be contrived.
>
> Call the steering wheel Steering_Wheel, and call the type something like
> Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names
> and variable names to be lexically distinguished, so the EuLisp/Dylan
> convention, which would be to name it something like <SteeringWheel>,
> would be my choice if I could do it all myself, but I don't think the
> _Type convention is bad at all, and its used widely in my Ada reference
> of choice (Ada as a Second Language).

The Eiffel convention is to use uppercase for class names and lowercase for
feature names.	Does this fit the bill?  Some compilers won't even accept
source code that does not follow this convention, so other programmers not
conforming is not an issue.

> If you want to talk about having to create contrived names, be careful,
> Eiffel doesn't have overloading, which is far worse IMO. Apparently the
> Sather designers agreed, when they decided to "fix" Eiffel, they added
> overloading. Other languages, like OCaml, do away with most of the need
> to name types altogether, so the antiredundantists should consider such
> languages before disparaging the Ada way in deference to Eiffel way.

Perhaps, but preventing redundancy is still a good thing, so the fact that a
language is redundant in one sense doesn't change the fact that eliminating
redundancy in another sense is a Good Thing.

> pragma Rant(On);
>
> The truth is I don't think I'll use Eiffel again, because I don't think
> its a very good language design. I think OO is overrated, and languages
> that try to enforce OO as the *only* programming tool are not for me. I
> like Eiffel's assertion mechanisms (though I'm not sure they belong in the
> language or would be better left as a tool) but I think its type system is
> hopelessly broken, it *requires* whole-program analysis due to covariance;
> bye-bye separate compilation!

Fair enough.  I don't like covariance either.  But as for whole-program
analysis...

First, this is not necessary if you're satisfied with some type checking being
done at runtime.  So the accurate assessment would be that whole-program
analysis is required for static type safety, rather than to make Eiffel usable
at all.

Second, SmallEiffel is a compiler which has dived whole-heartedly into a
system-wide approach, and as such is able to make *massive* optimisations
which produce excellent executables.  Since the compiler is compiled by
itself, it makes use of these optimisations to provide system-wide
compilation which is of comparable speed to module-wise compilation systems.

In fact, because SmallEiffel compiles to C, it is possible to compare the
system-wide approach to the module-wise approach directly, and the Eiffel-to-C
phase of compilation is invariably faster than the C-to-native phase, often by
an order of magnitude, despite the fact that the C-to-native phase only
compiles the portions that have changed.  It is dangerous to draw too many
conclusions from this, but one thing that is clear is that the system-wide
approach does not have a significant impact on compile time.

> Obviously, people are free to have different opinions, and I wouldn't want
> to start another Eiffel/Ada flamefest, so I generally avoid posting my
> opinion on the Eiffel ng.

That's probably the safest thing to do.  :-)

 -PD

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Mon, 10 Aug 1998 doylep@ecf.toronto.edu wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > Call the steering wheel Steering_Wheel, and call the type something like
> > Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names
> > and variable names to be lexically distinguished, so the EuLisp/Dylan
> > convention, which would be to name it something like <SteeringWheel>,
> > would be my choice if I could do it all myself, but I don't think the
> > _Type convention is bad at all, and its used widely in my Ada reference
> > of choice (Ada as a Second Language).
> 
> The Eiffel convention is to use uppercase for class names and lowercase for
> feature names.	Does this fit the bill?  Some compilers won't even accept
> source code that does not follow this convention, so other programmers not
> conforming is not an issue.

Well, its definitely lexically distinguishable in a case sensitive
language, but as I said earlier, I find it aesthetically unappealling to
rely on case alone for the distinction. Even in C and Java, I use 
more than case to distinguish. Personally, I don't mind a little
redundancy, and I find all of this talk of "noise" in the type name really
funny, as though its somehow really difficult for the reader to deal with 
this _Type business. 

However, as I also said, if I were to use Eiffel or a similar language
long enough, I'm pretty sure I'd get used to it, even if I don't like 
that convention now. 
 
> > If you want to talk about having to create contrived names, be careful,
> > Eiffel doesn't have overloading, which is far worse IMO. Apparently the
> > Sather designers agreed, when they decided to "fix" Eiffel, they added
> > overloading. Other languages, like OCaml, do away with most of the need
> > to name types altogether, so the antiredundantists should consider such
> > languages before disparaging the Ada way in deference to Eiffel way.
> 
> Perhaps, but preventing redundancy is still a good thing, so the fact that a
> language is redundant in one sense doesn't change the fact that eliminating
> redundancy in another sense is a Good Thing.

You're absolutely correct here. However, I don't think Ada will change
(in this regard) anytime to soon, nor will Eiffel adopt overloading, so 
I think if I have a choice, I find overloading to be a more useful
feature in eliminating redundancy in name choice. 

If you really want to look at eliminating redundancy, look at languages
which do are indentation sensitive (Python, Haskell, ...) and eliminate
all of those noisy begin...end pairs. 1/2 :-)
 
... snip ...
> 
> Fair enough.  I don't like covariance either.  But as for whole-program
> analysis...
> 
> First, this is not necessary if you're satisfied with some type checking being
> done at runtime.  

And significantly less optimization too, at that point. 

> So the accurate assessment would be that whole-program
> analysis is required for static type safety, rather than to make Eiffel usable
> at all.

If you are willing to forego static checking, why use Eiffel or Ada at
all?
 
> Second, SmallEiffel is a compiler which has dived whole-heartedly into a
> system-wide approach, and as such is able to make *massive* optimisations
> which produce excellent executables.  Since the compiler is compiled by
> itself, it makes use of these optimisations to provide system-wide
> compilation which is of comparable speed to module-wise compilation systems.

Nothing stops you from getting the best of both worlds in Ada, since
nothing in Ada precludes you from doing whole program analysis, that is 
assuming you have the whole program to analyze. In Eiffel, you have to do 
whole program analysis to get type safety, and I don't believe that any 
Eiffel compiler even does the entire analysis (system level validity
checking, or now polymorphic catcall checking?), so I just can't see 
this as being an Eiffel advantage. Just for my education, do any current
Eiffel compilers actually do all of the analysis?

> In fact, because SmallEiffel compiles to C, it is possible to compare the
> system-wide approach to the module-wise approach directly, and the Eiffel-to-C
> phase of compilation is invariably faster than the C-to-native phase, often by
> an order of magnitude, despite the fact that the C-to-native phase only
> compiles the portions that have changed.  It is dangerous to draw too many
> conclusions from this, but one thing that is clear is that the system-wide
> approach does not have a significant impact on compile time.

Sorry, I don't believe it. A language with separately compiled modules
will always have an advantage here; as I said above, you could apply the
same technology to Ada or a similar language, and you'd be guaranteed type
safety too, whereas with Eiffel you really have to check the whole program
or defer some checks until run time. Seems to defeat the purpose of static
checking at that point.

-- Brian

Re: Naming of Tagged Types and Associated Packages

[John Volan]

Brian Rogoff wrote:
> 
> Well, its definitely lexically distinguishable in a case sensitive
> language, but as I said earlier, I find it aesthetically unappealling to
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
> rely on case alone for the distinction. Even in C and Java, I use
> more than case to distinguish. Personally, I don't mind a little
> redundancy, and I find all of this talk of "noise" in the type name really
> funny, as though its somehow really difficult for the reader to deal with
> this _Type business.

Although I don't count myself among them [*], I'm pretty sure that the
people who object to the "_Type" convention in Ada do so not because
they feel that this "noise" somehow reduces understandability, but
rather purely as a matter of taste. To them, having a type name _say_
that it is a type name, when this fact can simply be deduced from
context, or by looking up the declaration, amounts to "catering to the
programming language".  This seems to disturb their aesthetic
sensibilities somehow -- just as relying on case distinctions seems to
disturb your aesthetic sensibilities, Brian.

[*] I should say, I don't object to "_Type" -- and indeed I advocate it
-- if one is programming in Ada.  It seems to be the best compromise
given the properties of that language.  On the other hand, if one is
programming in Java, C++, Eiffel, or Smalltalk, I'd advocate exploiting
case conventions for all they're worth, and don't bother with "_Type".

> However, as I also said, if I were to use Eiffel or a similar language
> long enough, I'm pretty sure I'd get used to it, even if I don't like
> that convention now.

Exactly.

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );

Re: Naming of Tagged Types and Associated Packages

[John Volan]

Brian Rogoff wrote:
> 
> Well, its definitely lexically distinguishable in a case sensitive
> language, but as I said earlier, I find it aesthetically unappealling to
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
> rely on case alone for the distinction. Even in C and Java, I use
> more than case to distinguish. Personally, I don't mind a little
> redundancy, and I find all of this talk of "noise" in the type name really
> funny, as though its somehow really difficult for the reader to deal with
> this _Type business.

Although I don't count myself among them [*], I'm pretty sure that the
people who object to the "_Type" convention in Ada do so not because
they feel that this "noise" somehow reduces understandability, but
rather purely as a matter of taste. To them, having a type name _say_
that it is a type name, when this fact can simply be deduced from
context, or by looking up the declaration, amounts to "catering to the
programming language".  This seems to disturb their aesthetic
sensibilities somehow -- just as relying on case distinctions seems to
disturb your aesthetic sensibilities, Brian.

[*] I should say, I don't object to "_Type" -- and indeed I advocate it
-- if one is programming in Ada.  It seems to be the best compromise
given the properties of that language.  On the other hand, if one is
programming in Java, C++, Eiffel, or Smalltalk, I'd advocate exploiting
case conventions for all they're worth, and don't bother with "_Type".

> However, as I also said, if I were to use Eiffel or a similar language
> long enough, I'm pretty sure I'd get used to it, even if I don't like
> that convention now.

Exactly.

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );

Re: Naming of Tagged Types and Associated Packages

[doylep]

In article <Pine.BSF.3.96.980810163352.29141A-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
>
> On Mon, 10 Aug 1998 doylep@ecf.toronto.edu wrote:
> >
> > The Eiffel convention is to use uppercase for class names and lowercase for
> > feature names.  Does this fit the bill?  Some compilers won't even accept
> > source code that does not follow this convention, so other programmers not
> > conforming is not an issue.
>
> Well, its definitely lexically distinguishable in a case sensitive
> language, but as I said earlier, I find it aesthetically unappealling to
> rely on case alone for the distinction.

Well, it would be compiler-enforced case sensitivity *in addition* to
different namespaces, but I think I get your point.

> However, as I also said, if I were to use Eiffel or a similar language
> long enough, I'm pretty sure I'd get used to it, even if I don't like
> that convention now.

Right.  Fair enough.

> If you really want to look at eliminating redundancy, look at languages
> which do are indentation sensitive (Python, Haskell, ...) and eliminate
> all of those noisy begin...end pairs. 1/2 :-)

True.  I've seen those, and I probably find that about as distasteful as you
do Eiffel's conventions.  However, as you say, I'm sure I'd get used to it.

> > Fair enough.  I don't like covariance either.  But as for whole-program
> > analysis...
> >
> > First, this is not necessary if you're satisfied with some type checking
> > being done at runtime.
>
> And significantly less optimization too, at that point.

Well, I'm not sure that's the case.  All that is needed is a check to make
sure that an object conforms; after that, it can be assumed that it conforms,
with all the implications that would have arisen if that could have been
proven at compile time.

Besides, because I dislike covariance, I don't use it, so I don't pay any
penalty for it.

> If you are willing to forego static checking, why use Eiffel or Ada at
> all?

Hey, let's be fair here; we're not really foregoing static checking.  You can
have it if you don't use covariance.  And if you do use covariance, well then
yes, you are foregoing static checking in those cases, so it's a tradeoff.
However, even in such cases, Eiffel still offers the advantages of Design By
Contract, plus its nice data type and algorithm libraries, which may be enough
to make one want to use Eiffel even without 100% static type checking.

> > Second, SmallEiffel is a compiler which has dived whole-heartedly into a
> > system-wide approach, and as such is able to make *massive* optimisations
> > which produce excellent executables.  Since the compiler is compiled by
> > itself, it makes use of these optimisations to provide system-wide
> > compilation which is of comparable speed to module-wise compilation systems.
>
> Nothing stops you from getting the best of both worlds in Ada, since
> nothing in Ada precludes you from doing whole program analysis, that is
> assuming you have the whole program to analyze.

True.  My real point is a much weaker one: simply that such compilers for
Eiffel actually *exist* whereas (correct me if I'm wrong) they don't exist
for Ada or any other language.	In fact, the people who wrote the SmallEiffel
compiler pioneered some techniques in system-wide optimizations, so I can say
with some certainty that these things are not in any other compilers.

Certainly the issue of what compilers *could* do is much more nebulous, and
IMHO less relevant to language choices than what compilers *actually* do. 
(This is a double-edged sword, of course, since it cancels my point that
Eiffel compilers *could* do system validity checks.  :-)

> In Eiffel, you have to do
> whole program analysis to get type safety, and I don't believe that any
> Eiffel compiler even does the entire analysis (system level validity
> checking, or now polymorphic catcall checking?), so I just can't see
> this as being an Eiffel advantage. Just for my education, do any current
> Eiffel compilers actually do all of the analysis?

I believe there are no such compilers currently available.

Don't get me wrong: I don't think the fact that Eiffel *requires* system
validity checking is a good thing.  Personally, I'd like to see covariance and
feature hiding banished.

> > In fact, because SmallEiffel compiles to C, it is possible to compare the
> > system-wide approach to the module-wise approach directly, and the
Eiffel-to-C
> > phase of compilation is invariably faster than the C-to-native phase, often
by
> > an order of magnitude, despite the fact that the C-to-native phase only
> > compiles the portions that have changed.  It is dangerous to draw too many
> > conclusions from this, but one thing that is clear is that the system-wide
> > approach does not have a significant impact on compile time.
>
> Sorry, I don't believe it. A language with separately compiled modules
> will always have an advantage here; as I said above, you could apply the
> same technology to Ada or a similar language, and you'd be guaranteed type
> safety too, whereas with Eiffel... [points already covered above]

Well, separately-compiled units are largely an illusion anyway, since any
build process (that I'm aware of) requires at least one step which is
system-wide. With C, for instance, the link phase is system-wide, and so is
the dependency-checking phase (say, with makefiles).

So separate compilation does not provide a different order of complexity
versus system-wide approaches.	At best it has a smaller multiplier; in the
case of SmallEiffel vs. C, it has been my experience that even this is not
the case.

 -PD

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

I think we've strayed far from the naming discussion, so maybe we should 
continue this on comp.lang.misc, since some other languages besides Ada 
are being discussed, or privately via e-mail. I have no interest in
expanding the newsgroups line, and I'm beginning to think that
crossposting in general is a questionable practice. 

On Tue, 11 Aug 1998 doylep@ecf.toronto.edu wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > If you really want to look at eliminating redundancy, look at languages
> > which do are indentation sensitive (Python, Haskell, ...) and eliminate
> > all of those noisy begin...end pairs. 1/2 :-)
> 
> True.  I've seen those, and I probably find that about as distasteful as you
> do Eiffel's conventions.  However, as you say, I'm sure I'd get used to it.

Indeed, you may even find that here are certain advantages to this choice. 
I found it rather unnerving at first myself. I don't have a lot of
experience with these languages, so I can't say how I'll feel in a few
years time. My Python programs have tended to be small, and Haskell is
more of an academic curiosity to me than a language that I'd use for real
programming. Maybe one day...

> > > Fair enough.  I don't like covariance either.  But as for whole-program
> > > analysis...
> > >
> > > First, this is not necessary if you're satisfied with some type checking
> > > being done at runtime.
> >
> > And significantly less optimization too, at that point.
> 
> Well, I'm not sure that's the case.  All that is needed is a check to make
> sure that an object conforms; after that, it can be assumed that it conforms,
> with all the implications that would have arisen if that could have been
> proven at compile time.

I think if you keep type information around at run time, you've sacrificed 
some optimization, right?

> Besides, because I dislike covariance, I don't use it, so I don't pay any
> penalty for it.

But you also can't use anyone else's Eiffel program if they don't share 
your dislike, else you'll pay the penalty. 

It almost sounds like you were a Sather user, or at least that you'd have
really liked Sather.

> > If you are willing to forego static checking, why use Eiffel or Ada at
> > all?
> 
> Hey, let's be fair here; we're not really foregoing static checking.  You can
> have it if you don't use covariance.  And if you do use covariance, well then
> yes, you are foregoing static checking in those cases, so it's a tradeoff.
> However, even in such cases, Eiffel still offers the advantages of Design By
> Contract, 

I agree that Eiffel's built in assertion mechanisms are very nice, and
more powerful than what we have in Ada. I also think that external tools 
could provide many of the same advantages, and maybe even provide more.

But I accept that my statement is unfair, and you may like Eiffel at many
levels.

> plus its nice data type and algorithm libraries, which may be enough
> to make one want to use Eiffel even without 100% static type checking.

Eiffel lacks the ability to do system level programming (low level
mucking) so I'm not sure that its data types are really more powerful than
what you get in Ada. 

> > Nothing stops you from getting the best of both worlds in Ada, since
> > nothing in Ada precludes you from doing whole program analysis, that is
> > assuming you have the whole program to analyze.
> 
> True.  My real point is a much weaker one: simply that such compilers for
> Eiffel actually *exist* whereas (correct me if I'm wrong) they don't exist
> for Ada or any other language.	In fact, the people who wrote the SmallEiffel
> compiler pioneered some techniques in system-wide optimizations, so I can say
> with some certainty that these things are not in any other compilers.

The Scheme compiler Stalin, at 

	http://www.neci.nj.nec.com/homepages/qobi/software.html

does extensive system wide optimizations, and compiles Scheme down to some 
mighty fast C. Whether other compilers do exactly what SmallEiffel does is 
probably not relevant, Eiffel needs certain optimizations to be fast,
Scheme needs others, and Ada probably others still.

I don't know of any Ada compilers which do whole program optimization.

> Certainly the issue of what compilers *could* do is much more nebulous, and
> IMHO less relevant to language choices than what compilers *actually* do. 

Very true, and also relevant to my comment about DBC as an external tool
for Ada; since it hasn't been done I shouldn't claim that the possibility
of doing negates the Eiffel advantage here, so I don't.

> I believe there are no such compilers currently available.
> 
> Don't get me wrong: I don't think the fact that Eiffel *requires* system
> validity checking is a good thing.  Personally, I'd like to see covariance and
> feature hiding banished.

Have you looked at Sather? It looks like what you want, though it seems 
moribund now.

> > Sorry, I don't believe it. A language with separately compiled modules
> > will always have an advantage here; as I said above, you could apply the
> > same technology to Ada or a similar language, and you'd be guaranteed type
> > safety too, whereas with Eiffel... [points already covered above]
> 
> Well, separately-compiled units are largely an illusion anyway, since any
> build process (that I'm aware of) requires at least one step which is
> system-wide. With C, for instance, the link phase is system-wide, and so is
> the dependency-checking phase (say, with makefiles).

Sure, but different groups can develop independent modules in Ada, compile 
pieces independently, and link them together in the end and be sure that
the result contains no type violations (there could be other violations,
like range violations, which would correspond to violated assertions in 
Eiffel). This is not true of Eiffel.

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I think if you keep type information around at run time, you've sacrificed 
> some optimization, right?

I don't think so.  For example, consider "Mumble(T'Class(X));" in Ada,
or X.Mumble in Eiffel.  Both dispatch to the appropriate implementation
of Mumble at run time, and both need to have "type information" around
at run time to do so.  If that type info weren't automatically kept
around, the programmer would have to keep that same information
explicitly.  Note that the type info isn't being used here to perform
run-time type checking; in both languages, there's guaranteed to be an
appropriate Mumble to call.

> I agree that Eiffel's built in assertion mechanisms are very nice, and
> more powerful than what we have in Ada. I also think that external tools 
> could provide many of the same advantages, and maybe even provide more.

I'd be interested in seeing a design for such external tools.

> Sure, but different groups can develop independent modules in Ada, compile 
> pieces independently, and link them together in the end and be sure that
> the result contains no type violations (there could be other violations,
> like range violations, which would correspond to violated assertions in 
> Eiffel). This is not true of Eiffel.

It seems sort of silly to say, "Language X catches all *type* errors at
compile time, but of course there are other errors that are caught only
at run time", since the language definition defines what's a "type
error" and what's an "other error".  Eg Ada catches variant record
errors at run time.  One could reasonably call those "type errors", but
the language definition says they're merely "constraint check failures".

I can easily define a language that catches *all* type errors at compile
time, merely by defining "type error" to match what happens to be caught
at compile time.

Some folks would consider "divide by zero" to be a type error.
But most languages catch it at run time.  I could force it to be caught
at compile time, but it might not improve the programming language.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Thu, 13 Aug 1998, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > I think if you keep type information around at run time, you've sacrificed 
> > some optimization, right?
> 
> I don't think so.  For example, consider "Mumble(T'Class(X));" in Ada,
> or X.Mumble in Eiffel.  Both dispatch to the appropriate implementation
> of Mumble at run time, and both need to have "type information" around
> at run time to do so. 

But if T'Class(X), or X, can be determined to only be of one type by the 
compiler, keeping the tag around at run time is potentially less optimal 
than eliminating it. Thats what I was talking about, eliminating all of 
the tags that you can, rather tthan schlepping them around. 

> > I agree that Eiffel's built in assertion mechanisms are very nice, and
> > more powerful than what we have in Ada. I also think that external tools 
> > could provide many of the same advantages, and maybe even provide more.
> 
> I'd be interested in seeing a design for such external tools.

The Larch toolkit is one attempt, though it seems that there is no Larch
for Ada 95. LCLint is pretty useful for C programs, though I haven't used
it for large (> 100KLOC of C being large) programs. 

Anna was also an attempt, long dead by now. 

Maybe a big problem of Ada is that it is good enough at eliminating 
many problems that noone feels the effort of going further is worth it, 
unlike C, or "the squeaky wheel gets the grease". 

More likely is that Ada is not popular enough to justify the investment.
 
> > Sure, but different groups can develop independent modules in Ada, compile 
> > pieces independently, and link them together in the end and be sure that
> > the result contains no type violations (there could be other violations,
> > like range violations, which would correspond to violated assertions in 
> > Eiffel). This is not true of Eiffel.
> 
> It seems sort of silly to say, "Language X catches all *type* errors at
> compile time, but of course there are other errors that are caught only
> at run time", since the language definition defines what's a "type
> error" and what's an "other error".  Eg Ada catches variant record
> errors at run time.  One could reasonably call those "type errors", but
> the language definition says they're merely "constraint check failures".

Fair enough. However, if you accept Eiffel's own definition of what its 
types are (I'm not talking about assertion violations), then Eiffel is 
not statically type safe in any realistic sense, since there is not now
and has never been an Eiffel compiler which does full type checking of an
Eiffel program at compile time. Eiffel advocates will claim its not
important, and that serious users don't complain about this, but hey,
serious users of Smalltalk and CLOS don't complain that their lack of
static typing is a practical problem either, quite the opposite, they'll 
claim it leads to fewer bugs.

> I can easily define a language that catches *all* type errors at compile
> time, merely by defining "type error" to match what happens to be caught
> at compile time.

I still think constraint violations are more like assertion violations
than type errors, but you're entitled to your opinion of course, and can 
define things as you like.

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Robert A Duff <bobduff@world.std.com> writes:

> > I agree that Eiffel's built in assertion mechanisms are very nice, and
> > more powerful than what we have in Ada. I also think that external tools 
> > could provide many of the same advantages, and maybe even provide more.
> 
> I'd be interested in seeing a design for such external tools.

Whatever happened to ANNA?

Re: Naming of Tagged Types and Associated Packages

[Dale Stanbrough]

Matthew Heaney wrote:

"Whatever happened to ANNA?"


Not much. It just sits quietly in a dusty corner of a hard disc
drive at Stanford, waiting for someone to update it to Ada95, and
use ASIS as the parsing engine.

Dale

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dale@cs.rmit.edu.au (Dale Stanbrough) writes:

> Matthew Heaney wrote:
> 
> "Whatever happened to ANNA?"
> 
> 
> Not much. It just sits quietly in a dusty corner of a hard disc
> drive at Stanford, waiting for someone to update it to Ada95, and
> use ASIS as the parsing engine.

I seems like this would be the idle environment-based tool to use to add
pre- and postcondition checks to the language.

You seem to know something about what's under the hood.  How much effort
are we talking about to make the update happen?  Is is a one-person job
part time?  Full time?

Re: Naming of Tagged Types and Associated Packages

[Bob Collins]

In article <m3r9xwocgy.fsf@mheaney.ni.net>, Matthew Heaney
<matthew_heaney@acm.org> wrote:

[about Anna]

> I seems like this would be the idle environment-based tool to use to add
> pre- and postcondition checks to the language.

Idle because it's not being used?

-- 
Bob Collins  <mailto:collins@cs.wm.edu>  <http://ratbert.cs.wm.edu>

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

collins@cs.wm.edu (Bob Collins) writes:

> > I seems like this would be the idle environment-based tool to use to add
> > pre- and postcondition checks to the language.
> 
> Idle because it's not being used?

Oops!  Fast but sloppy fingers I'm afraid.  I meant "ideal."

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> dale@cs.rmit.edu.au (Dale Stanbrough) writes:
> 
> > Matthew Heaney wrote:
> >
> > "Whatever happened to ANNA?"
> >
> >
> > Not much. It just sits quietly in a dusty corner of a hard disc
> > drive at Stanford, waiting for someone to update it to Ada95, and
> > use ASIS as the parsing engine.
> 
> I seems like this would be the idle environment-based tool to use to add
> pre- and postcondition checks to the language.

"Idle"?  Matt, I think your Freudian slip is showing... ;-)

-- 
indexing
   description: "Signatures for John Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %uniform access, generics, true MI, feature adaptation, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Brian Rogoff wrote:

:Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond
:to this in c.l.e., as I remember several language wars starting from
:c.l.ada/eiffel crossposting, and I just don't care for them.

BTW, I cross-posted because Eiffel was being discussed and others 
(Patrick, in this case) may have wanted to participate. My intention 
wasn't to re-ignite a language war. I don't have the time or inclination 
to participate in one.


Presumably, you think it's clearer, in Ada, if variables and types have 
different identifiers. That may be true and the decision to require this 
a language rule may be the right one for Ada.

For Eiffel, I think allowing use of the same identifier is the right 
policy as the simpler syntax is unlikely to cause confusion.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Pat Rogers]

Don Harrison wrote in message ...
>Brian Rogoff wrote:
>
>:Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond
>:to this in c.l.e., as I remember several language wars starting from
>:c.l.ada/eiffel crossposting, and I just don't care for them.
>
>BTW, I cross-posted because Eiffel was being discussed and others
>(Patrick, in this case) may have wanted to participate. My intention
>wasn't to re-ignite a language war. I don't have the time or inclination
>to participate in one.


I was surprised to see mention of a c.l.ada/eiffel war.  I wasn't following all
such threads terribly closely, partly because of the venom oozing out of the
C++/Eiffel wars.   I've found the Ada/Eiffel discussions polite and very
informative, and hope they continue when sufficient interest exists.

-- pat

Patrick Rogers
progers@acm.org
http://www.neosoft.com/~progers

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Pat Rogers wrote:

:Don Harrison wrote in message ...
:>Brian Rogoff wrote:
:>
:>:Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond
:>:to this in c.l.e., as I remember several language wars starting from
:>:c.l.ada/eiffel crossposting, and I just don't care for them.
:>
:>BTW, I cross-posted because Eiffel was being discussed and others
:>(Patrick, in this case) may have wanted to participate. My intention
:>wasn't to re-ignite a language war. I don't have the time or inclination
:>to participate in one.
:
:
:I was surprised to see mention of a c.l.ada/eiffel war.  I wasn't following all
:such threads terribly closely, partly because of the venom oozing out of the
:C++/Eiffel wars.   I've found the Ada/Eiffel discussions polite and very
:informative, and hope they continue when sufficient interest exists.

I agree the current tenor of discussion between Eiffel and Ada advocates 
is positive. There have been some heated debates in the past which haven't 
been too constructive. My own criticism of Ada has probably led some to 
believe I have no appreciation of the language. This isn't true. I happen
to prefer Eiffel, though I would choose Ada in preference to C++ any day.

Eiffel and Ada advocates are often passionate about their favourite 
language and crossposting carries the risk of sparking a bun-fight. 
However, it can also help clear up misconceptions about each.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

nospam@thanks.com.au (Don Harrison) writes:

> Eiffel and Ada advocates are often passionate about their favourite 
> language and crossposting carries the risk of sparking a bun-fight. 
> However, it can also help clear up misconceptions about each.

This was indeed the case on comp.object recently.  I was able to show
some Eiffel guys how importing an operation as a generic formal
subprogram eliminates the coupling that would occur by using multiple
inheritance to compose abstractions.

All and all, I'd say USENET is worth it.

Re: Naming of Tagged Types and Associated Packages

[Robert A Duff]

doylep@ecf.toronto.edu writes:

> Yes, that's the same reason I am usually too afraid to venture into c.l.a. 
> :-)

I wish we could all discuss the advantages and disadvantages of specific
features of programming languages, without getting into the "My Language
is better than Your Language" mode.

Oh, well.

> The Eiffel convention is to use uppercase for class names and lowercase for
> feature names.  Does this fit the bill?  Some compilers won't even accept
> source code that does not follow this convention, so other programmers not
> conforming is not an issue.

The "some compilers" above introduces another point: Shouldn't the
language standard specify one way or the other?!

> > Obviously, people are free to have different opinions, and I wouldn't want
> > to start another Eiffel/Ada flamefest, so I generally avoid posting my
> > opinion on the Eiffel ng.
> 
> That's probably the safest thing to do.  :-)

Sigh.  ;-)

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Thu, 13 Aug 1998, Robert A Duff wrote:
> I wish we could all discuss the advantages and disadvantages of specific
> features of programming languages, without getting into the "My Language
> is better than Your Language" mode.

But the appropriate place to discuss such things is probably
comp.lang.misc, or comp.object, or comp.software-eng, or ... 

Crossposted threads, even very polite ones, tend to be noise for people 
who, for example, only want to read about Ada on the Ada ng, or Eiffel on 
the Eiffel ng, or Lisp on the Lisp ng, etc. I'm sure many people in the 
Eiffel ng feel the same way, and just aren't interested in Ada, or Forth,
or Python. (Whew, lots of or-ing in this post!)

-- Brian

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Brian Rogoff wrote (in comp.lang.ada):

: .. I'm sure many people in the 
:Eiffel ng feel the same way, and just aren't interested in Ada, ..

This may come as a shock to you, Brian, but the number of cross-posted 
Eiffel-Ada threads in the last few years has increased interest in 
Ada among members of the Eiffel community. From your perspective, that 
can't be a bad thing, can it?

Interest in Eiffel among members of the Ada community has also increased 
and we consider that a good thing. :)

These discussions have allowed each side to appreciate what the other 
language has to contribute to software engineering and has dispelled 
at least some of the inevitable misconceptions that come with looking 
from the other side of the fence.

I think Eiffel and Ada developers can learn a lot from each other and 
hope that polite cross-posted discussions continue. Anyone who doesn't 
want to contribute positively is welcome to keep quiet.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Don Harrison a �crit dans le message ...
[...]
>I think Eiffel and Ada developers can learn a lot from each other and
>hope that polite cross-posted discussions continue. Anyone who doesn't
>want to contribute positively is welcome to keep quiet.
>
2 cts of information:
There IS a connection between Eiffel and Ada. The syntax of Eiffel was
inspired by Ada, and B. Meyer was the founder of the Ada group at AFCET
(which later became Ada-France).

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Jean-Pierre Rosen wrote:

:There IS a connection between Eiffel and Ada. The syntax of Eiffel was
:inspired by Ada, and B. Meyer was the founder of the Ada group at AFCET
:(which later became Ada-France).

Yes, the influence of Ada on the design of Eiffel is unmistakeable. 

Interestingly, no syntax from C found its way into Eiffel. .. which 
isn't so surprising.  :)


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Bob Duff wrote:

:doylep@ecf.toronto.edu writes:

:> The Eiffel convention is to use uppercase for class names and lowercase for
:> feature names. [..] Some compilers won't even accept
:> source code that does not follow this convention ..
:
:The "some compilers" above introduces another point: Shouldn't the
:language standard specify one way or the other?!

Standard Eiffel is case-insensitive. I'm not sure which compiler Patrick 
is referring to, but if it enforces any case convention, it's a 
non-compliant implementation.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[doylep]

In article <ExnKrB.G63@syd.csa.com.au>,
  nospam@thanks.com.au wrote:
>
> Standard Eiffel is case-insensitive.

Indeed, this is correct.

> I'm not sure which compiler Patrick
> is referring to, but if it enforces any case convention, it's a
> non-compliant implementation.

SmallEiffel generates warnings for identifiers which do not conform to the
standard Eiffel conventions for upper/lower case.  (Incidentally, by default,
SmallEiffel is also case sensitive; this is disabled with a compiler flag. 
I'm not sure why it was done this way.)

 -PD

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Patrick Doyle wrote:

:In article <ExnKrB.G63@syd.csa.com.au>,
:  nospam@thanks.com.au wrote:
:>
:> Standard Eiffel is case-insensitive.
:
:Indeed, this is correct.

Thanks for confirming that for me.  :)


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Brian Rogoff wrote (in comp.lang.ada):

:The truth is I don't think I'll use Eiffel again, because I don't think 
:its a very good language design. I think OO is overrated, and languages
:that try to enforce OO as the *only* programming tool are not for me. 

You do realise, of course, that you can use Eiffel in a non-OO way
if you so choose (no inheritance, polymorphism; use selective export to 
co-encapsulate abstractions etc.) but it would be a bit like using the nail 
file of a Swiss Army knife for cutting, opening tin cans etc. when those 
respective attachments are also available.

:I like Eiffel's assertion mechanisms (though I'm not sure they belong in the
:language or would be better left as a tool) but I think its type system is 
:hopelessly broken, it *requires* whole-program analysis due to covariance;
:bye-bye separate compilation! 

I've yet to come across a serious Eiffel user who bemoans the fact that 
system validity is currently a runtime phenomenon. Those complaining 
invariably aren't Eiffel users.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

doylep@ecf.toronto.edu writes:

> 2. It allows you to avoid contrivances by permitting things like this:
> 
> class CAR
> 
> feature
>     steering_wheel : STEERING_WHEEL
> 
> end
> 
> What else are you going to call the steering wheel?  A
> direction_control_device? I think any other name would be contrived.

I usually qualify auxiliary types with the name of the "main" type, so I
probably would have named the type Car_Steering_Wheel, and the object
Steering_Wheel.

package Cars is

   type Car_Steering_Wheel is ...;

   type Car is
      tagged record
        Steering_Wheel : Car_Steering_Wheel;
      end record;


This is the convention used in package Text_IO, for type File_Mode.

This is another reason why use clauses are safe.  The naming convention
makes it obvious that type Car_Steering_Wheel is declared package Cars.

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> doylep@ecf.toronto.edu writes:
> 
> > 2. It allows you to avoid contrivances by permitting things like this:
> >
> > class CAR
> >
> > feature
> >     steering_wheel : STEERING_WHEEL
> >
> > end
> >
> > What else are you going to call the steering wheel?  A
> > direction_control_device? I think any other name would be contrived.
> 
> I usually qualify auxiliary types with the name of the "main" type, so I
> probably would have named the type Car_Steering_Wheel, and the object
> Steering_Wheel.
> 
> package Cars is
> 
>    type Car_Steering_Wheel is ...;
> 
>    type Car is
>       tagged record
>         Steering_Wheel : Car_Steering_Wheel;
>       end record;
> 
> This is the convention used in package Text_IO, for type File_Mode.
> 
> This is another reason why use clauses are safe.  The naming convention
> makes it obvious that type Car_Steering_Wheel is declared package Cars.

Matthew, you seem to be confusing P. Doyle's point.  (You seem to have
lost something in translation from Eiffel to Ada, not surprising.)  I'm
fairly certain that P. Doyle intended the "STEERING_WHEEL" type to be a
primary type in its own right, declared within its own module, and not
some auxiliary type subordinate to the "CAR" type, somehow declared
within the same module. (In fact, since P.D.'s example was Eiffel, the
"STEERING_WHEEL" type would _be_ its own module).

So your answer begs the question: What, then, would you call an instance
of the "CAR" type?

In Eiffel, the answer is fairly simple:

    car : CAR

The equivalent in Java would be:

    Car car;

(Let's please assume that we're in some context where there is only one
instance of the "CAR" type that happens to be of interest, so there's no
particular reason to attach some modifying adjective that distinguishes
that instance from any other instance of the "CAR" type.  This is by no
means a rare situation -- the above might be an argument to a method.)

It's interesting to note that the reasons this works out are very
different in Java as opposed to Eiffel:  

Java (like C++ and Smalltalk before it) is case-sensitive. This allows
programmers to get the _effect_ of two namespaces, by adopting a naming
convention in which a class name and a variable name may be the "same"
identifier, but differing in case.  In reality, the compiler considers
"car" and "Car" to be two completely distinct identifiers. Java really
has only one namespace (in any given scope), but this naming convention
effectively segregates that namespace into two mutually-exclusive
subsets.  Since the convention follows a regular rule (class names
initial uppercase, variable names initial lowercase), it is immediately
obvious to the programmer's eye into which subset a given identifier falls.

In Eiffel, the situation appears to be reversed: The compiler is
case-insensitive, but there actually _are_ two namespaces for type names
vs. entity names.  (That's interesting to me -- I had not known that
before.) So the Eiffel naming convention (type names all-uppercase;
entity names all-lowercase or mixed case) is purely a cosmetic
convenience for the human reader. To the compiler, "car" and "CAR"
really _are_ the same identifier, but the syntactic context allows the
compiler to distinguish which namespace to resolve the identifier against.

Ada has only one namespace (within any given scope). Since Ada is also
case-insensitive, the only recourse is to come up with completely
different identifiers for a variable and for its type.  

But the only difference between a variable and its type is that the
former is at a "base" level of abstraction, while the latter is at a
"meta" level of abstraction. Otherwise, they're just two manifestations
of a single "concept".  The base/meta distinction is fairly subtle;
people tend to want to gloss over it, and just use the same noun for
both "car" as a variable, and "CAR" as a type. 

It seems to me that if one is forced to come up with distinct
identifiers for a type and an (arbitrary) instance of that type, then
the difference between the identifiers should reflect this base/meta
distinction.  Thus, the Cohen style:

  Car : Car_Type;

In other words, the thing on the left hand side of the colon is a _car_,
while the thing on the right hand side a _type_ (the "car" type).

The old Booch style:

  The_Car : Car;

also reflects this same base/meta distinction. Using the definite
article in the variable name makes it clear that we're talking about a
specific instance of the concept (at the "base" level of abstraction),
whereas using the indefinite noun "Car" by itself indicates we're
talking at a more abstract level (the "meta" level).

It seems to me that any scheme that contrives different identifiers
without playing into the base/meta distinction is an ad hoc scheme. 

Matthew, you seem to be advocating a variation on the "abbreviation"
approach:  Come up with some wordy phrase for a type name, and then
arbitrarily lop off some part of that phrase to come up with a variable
name.  That seems ad hoc to me.

If it was important enough to say, in a type name, that something is a
"Car_Steering_Wheel" (as opposed to, perhaps, a "Truck_Steering_Wheel"),
then why isn't it also important to say "Car_Steering_Wheel" in the
variable name too?  Why arbitrarily lop off the "Car_" part?  

On the other hand, if the "Car_" part is already understood (because the
type is already nested inside a "Cars" package), then why bother with
the "Car_" part in the first place, in the type name?  Isn't that just
noise?  

If the type name were only "Steering_Wheel", what would you propose
lopping off from that to make the variable name? The "Steering_" part? 
Then why did we need to say "Steering_" in the type name?  Isn't that
just noise too?

On the other hand, what if the car doesn't just have a steering wheel,
but also has four drive wheels?  Then don't we need to say
"Steering_Wheel" and "Drive_Wheel", not only in the type names but also
in the variable names too?  What do we lop off where?

And what do you propose we lop off of the type name "Car" to make a
variable name?  Alternatively, what "noise" word shall we tack onto the
type name so we can then lop it off?

A naming convention should be systematic, mechanical, predictable and
transparent.  That means that it should take NO THOUGHT to apply it, or
to interpret the results. The argument that this limits a programmer's
creativity is specious.  There's plenty of opportunity for a software
engineer to be creative just in coming up with concepts like "Car" or
"Steering_Wheel" to program up.  That's the real critical design step. 
Going on to split each of these into base-level variable names and
meta-level type names should be a mechanical process, not something to
waste time over -- either for the code-writer, or more importantly for
the code-reader.

IMHO, the styles that Java and Eiffel allow meet the criteria of being
systematic, mechanical, etc.  In Ada, Cohen and Booch styles (and
Jean-Pierre Rosen's style, as a variation on Booch) also meet these
criteria, although at the cost of adding systematic "noise" (i.e.,
"_Type" or "The_").  But I am at a loss to see how Heaney style would
meet these criteria in the most general case.

-- 
Signature volanSignature =
  new Signature 
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon/TI Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i.*, " +
                    "so loading them throws DontQuoteMeError. :-) " );

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> Matthew Heaney wrote:
> > I usually qualify auxiliary types with the name of the "main" type, so I
> > probably would have named the type Car_Steering_Wheel, and the object
> > Steering_Wheel.
> > 
> > package Cars is
> > 
> >    type Car_Steering_Wheel is ...;
> > 
> >    type Car is
> >       tagged record
> >         Steering_Wheel : Car_Steering_Wheel;
> >       end record;
> > 
> > This is the convention used in package Text_IO, for type File_Mode.
> > 
> > This is another reason why use clauses are safe.  The naming convention
> > makes it obvious that type Car_Steering_Wheel is declared package Cars.
> 
> Matthew, you seem to be confusing P. Doyle's point.  (You seem to have
> lost something in translation from Eiffel to Ada, not surprising.)  I'm
> fairly certain that P. Doyle intended the "STEERING_WHEEL" type to be a
> primary type in its own right, declared within its own module, and not
> some auxiliary type subordinate to the "CAR" type, somehow declared
> within the same module. (In fact, since P.D.'s example was Eiffel, the
> "STEERING_WHEEL" type would _be_ its own module).

Your point highlights a difference between the two languages.  In Ada,
it's very natural to declare related ("cohesive") types in a single
module.  I was proceeding under the assumption that steering wheel type
didn't stand on its own; that it supported the larger car abstraction,
and hence was declared in the car module.

This is a very common idiom in Ada, where you have a single module that
exports one or more primary ADTs, supplemented by auxiliary types that
describe attributes of the primary abstraction(s).

> So your answer begs the question: What, then, would you call an instance
> of the "CAR" type?
> 
> In Eiffel, the answer is fairly simple:
> 
>     car : CAR
> 
> The equivalent in Java would be:
> 
>     Car car;
> 
> (Let's please assume that we're in some context where there is only one
> instance of the "CAR" type that happens to be of interest, so there's no
> particular reason to attach some modifying adjective that distinguishes
> that instance from any other instance of the "CAR" type.  This is by no
> means a rare situation -- the above might be an argument to a method.)

If it's the root of a tagged type hierarchy, then I would call it
Root_Car, just like they do in the RM (example: Root_Storage_Pool).
 
> Ada has only one namespace (within any given scope). Since Ada is also
> case-insensitive, the only recourse is to come up with completely
> different identifiers for a variable and for its type.  

This is indeed the case.  Which is why I think it's confusing to use
expanded name notation to differentiate between otherwise identical
names for object and type.  Use different identifiers for each.
 
> It seems to me that if one is forced to come up with distinct
> identifiers for a type and an (arbitrary) instance of that type, then
> the difference between the identifiers should reflect this base/meta
> distinction.  Thus, the Cohen style:
> 
>   Car : Car_Type;

Sometimes, if there really is no suitable adjective to describe the type
(or, you're just not feeling too creative that day), then you do have to
use _Type as the type name.  But I find those times to be rare.

> The old Booch style:
> 
>   The_Car : Car;
> 
> also reflects this same base/meta distinction.

I don't like this convention because it adds noise that the human reader
is going to mentally parse out anyway, so why not parse it out for him?
Better to name the type Car_Type, and the instance Car, becuase the
object is going to be refered to more often than the type itself.
 
> Matthew, you seem to be advocating a variation on the "abbreviation"
> approach:  Come up with some wordy phrase for a type name, and then
> arbitrarily lop off some part of that phrase to come up with a variable
> name.  That seems ad hoc to me.

I wouldn't call it ad hoc.  You don't come up with a "wordy" phrase for
the type name _arbitrarily_.  Just the opposite is true: you come up
with an adjective that applies to your abstraction.

A new member of the team I'm on declared a bunch of types (it was a
binding to a tape drive API) all using the _T convention.  I pointed out
to him that perhaps a better name would be to include the tape drive in
the type name, instead of using _T.

His rebuttal was to ask me how I'd name a color type.  My immediate
response is, "Well, what is it a color of?"  He said, "Say, a car."  So
my advice was, name the type Car_Color, not Color_Type.

Nor is the object name ad hoc: simply remove the adjective part of the
name, and keep the noun part.  Just like Mode is an instance of type
File_Mode, or File is an instance of File_Type, or Pool is an instance
of Static_Storage_Pool.

Another simple example: I like to name all scalar types with a dimension
by using the units in the name, as in

   Speed : Speed_In_MPH;
   Length : Length_In_Meters;

This solves the object-name type-name issue, and removes any ambiguity
about what units apply to the scalar type.  When refering to a literal,
I like to use a qualified name, as in

   Set_Speed (Car, Speed => Speed_In_MPH'(10.0));

to let the reader know that I really knew I was doing, setting the speed
to a value with units in miles per hour.  (It would also help if you
needed to change the units for some reason; the compiler would complain
about a now non-existent type.)

> If it was important enough to say, in a type name, that something is a
> "Car_Steering_Wheel" (as opposed to, perhaps, a "Truck_Steering_Wheel"),
> then why isn't it also important to say "Car_Steering_Wheel" in the
> variable name too?  Why arbitrarily lop off the "Car_" part?  

Because you only need to tell me once about the nature of the
abstraction.  We all know, by reading the _entire_ declaration (not just
the object name), that we're talking about the steering wheel of a car.

It _is_ important to tell my that this is a car steering wheel, but you
only need to tell me once (at declaration time), not tell me again and
again and again every time I refer to the object.  Because then it would
just become information the reader is going to mentally parse out.

So when I see an object called Mode, I know that this is a File_Mode,
because I read the subprogram from top to bottom, starting with the
declarative region, and noticed the declaration of object Mode.  Had I
started reading in the middle of the subprogram, and see object Mode, I
simply scan the program text backwards until I find the declaration.
(And if I have too scan far back, then the subprogram is probably too
long.)
 
> On the other hand, if the "Car_" part is already understood (because the
> type is already nested inside a "Cars" package), then why bother with
> the "Car_" part in the first place, in the type name?  Isn't that just
> noise?  

The Car_ part is there because we need to have a different name for the
type, because we want to call the object Steering_Wheel.

To use _Type really would be noise, because that doesn't tell me
anything I don't already know (even though it does satisfy the need to
use a different identifier for the type).

If we know that the object is going to be called Steering_Wheel, and
that we need a different (and longer) name for the type, then you might
as well add additional, substantive information about the abstraction
the type describes.

(Note that I'm proceeding here under that assumption that types don't
just float around in space; they're there for a reason, and steering
wheel abstractions "go with" car abstractions.  As they say, "No object
is an island.")
 
> If the type name were only "Steering_Wheel", what would you propose
> lopping off from that to make the variable name? The "Steering_" part? 
> Then why did we need to say "Steering_" in the type name?  Isn't that
> just noise too?

Precisely why I wouldn't name the type just Steering_Wheel.  Then the
object name would be Wheel, and that name has too many other potential
meanings.  The object name Steering_Wheel is unambiguous.
 
> On the other hand, what if the car doesn't just have a steering wheel,
> but also has four drive wheels?  Then don't we need to say
> "Steering_Wheel" and "Drive_Wheel", not only in the type names but also
> in the variable names too?  What do we lop off where?

You might decide on the convention that "Wheel" refers to drive wheels,
and "Steering_Wheel" refers to steering wheels.  

Or, you could lengthen the type names.  Name the type Drive_Wheel_Type
if you don't care for Car_Drive_Wheel.
 
> And what do you propose we lop off of the type name "Car" to make a
> variable name?  Alternatively, what "noise" word shall we tack onto the
> type name so we can then lop it off?

If we were manipulating a class-wide object, then the object name would
be Car the type Root_Car, as in

procedure Move (Car : in out Root_Car'Class);

This class-wide operation ("template method" for readers of the GoF
book) would dispatch primitive operations of types in the Root_Car
class.
 
> A naming convention should be systematic, mechanical, predictable and
> transparent.  That means that it should take NO THOUGHT to apply it, or
> to interpret the results.

Be careful not to assume that God decided that this is so.  This
description of a "good" naming convention is a choice YOU made.

In fact, I take the exact opposite position, and think that type names
require careful consideration of the application, the nature of the
abstraction, and of the intended names of instances.

Yes, this sometimes requires thinking (gasp!) and a certain amount of
creativity.

This is our real disagreement.  Clearly, you and I are arguing using a
different set of axioms.  No substantive debate can occur unless all
parties agree on first principles.

> The argument that this limits a programmer's creativity is specious.

I'm not suggested that mechanical application of a naming convention
limits a programmer's creativity.  In fact, the convention I advocate
often can be applied mechanically.

> But I am at a loss to see how Heaney style would meet these criteria
> in the most general case.

Please don't call this the Heaney style - call it the RM style.  My
argument isn't for a naming convention per se, it's that we should stick
to the conventions already being used in the language reference manual.

(But, like reading the Bible or the US Constitution, those conventions
are sometimes subject to interpretation, and aren't guaranteed to work
for anything but what's required to write a reference manual!)

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > (In fact, since P.D.'s example was Eiffel, the
> > "STEERING_WHEEL" type would _be_ its own module).
> 
> Your point highlights a difference between the two languages.  In Ada,
> it's very natural to declare related ("cohesive") types in a single
> module.  I was proceeding under the assumption that steering wheel type
> didn't stand on its own; that it supported the larger car abstraction,
> and hence was declared in the car module.
> 
> This is a very common idiom in Ada, where you have a single module that
> exports one or more primary ADTs, supplemented by auxiliary types that
> describe attributes of the primary abstraction(s).

Yes, this is an interesting idiom, and one may compare Ada's scheme of
grouping cohesive types within Ada packages with Java's scheme of
grouping cohesive classes within Java packages, or with Eiffel's scheme
of grouping cohesive classes within clusters using the Lace language.

However, this is off on a tangent from P. Doyle's question. P.D.'s
question (and mine) was essentially this:

You have a simple concept for some class of entities within your problem
domain, and you have come up with a short, pithy noun phrase (e.g.,
"CAR", "STEERING_WHEEL") that names this concept within the context of
your problem domain.  Let us assume that the verbiage in this noun
phrase is no more and no less than what is needed to convey the entire
problem-domain concept you have in mind; in other words, the component
words are at once necessary and sufficient. If that assumption is true,
then removing any words would yield an abbreviation, which is
insufficient; adding any words would create noise, which is unnecessary.
 Even words that convey the context of the problem domain are
unnecessary, since such context can either be assumed, or expressed as
module (package) names.

All things being equal, this necessary-and-sufficient noun phrase is
desirable both as an identifier for a type, and as an identifier for an
(arbitrary) variable of that type.  Every programming language requires
some mechanism for distinguishing such identifiers from each other. 
Ada's mechanism is to force the identifiers to be literally different,
which means either adding some kind of noise word to one or the other,
or resorting to abbreviation for one or the other. Many react with
distaste to either prospect, because they recognize both as catering to
the programming language, and not to the problem domain concept we are
trying to express. (Remember, the noun phrase in question is presumed to
be both necessary and sufficient to express the concept.)  Adding noise
seems less obnoxious than abbreviation. So what's the least obnoxious
noise you can add?

> > So your answer begs the question: What, then, would you call an instance
> > of the "CAR" type?
> >
> > In Eiffel, the answer is fairly simple:
> >
> >     car : CAR
...
> If it's the root of a tagged type hierarchy, then I would call it
> Root_Car, just like they do in the RM (example: Root_Storage_Pool).

I hope you recognize that "Root_" is as much a noise word as any other,
because it caters to the mechanisms of the language rather than to the
problem domain.  Most OO programmers would find it distasteful to mark
the class at the top of an inheritance hierarchy this way, simply
because it was at the top of an inheritance hierarchy.

But this is another tangent irrelevant to P.D.'s simple question, and it
doesn't address the general case.  What if, for the particular problem
domain at hand, "CAR" is _not_ intended as the top of an inheritance
hierarchy?  In fact, what if we even wanted to _preclude_ any
inheritance?  (In Ada terms, the Car type would be non-tagged.  In Java,
it would be a final class.  In Eiffel ... not sure of the syntax.)  In
that case, attaching the "Root_" prefix would not only be noise, it
would be misleading noise.  So the question remains: All things being
equal, what's the least noxious noise you can add, that will work even
in the most general case?

> ... I think it's confusing to use
> expanded name notation to differentiate between otherwise identical
> names for object and type.  Use different identifiers for each.

On this point, I agree.

> > It seems to me that if one is forced to come up with distinct
> > identifiers for a type and an (arbitrary) instance of that type, then
> > the difference between the identifiers should reflect this base/meta
> > distinction.  Thus, the Cohen style:
> >
> >   Car : Car_Type;
> 
> Sometimes, if there really is no suitable adjective to describe the type
> (or, you're just not feeling too creative that day), then you do have to
> use _Type as the type name.  But I find those times to be rare.

Again, I take exception to the notion that it is "uncreative" to be
systematic. I'd rather focus my creativity on the terminology of the
problem domain and not waste it on irrelevant artefacts of the coding process.

But I find it interesting that you fall back to my position as a sort of
default: When all else fails, use the base/meta (object/type)
distinction as a source for the extra noise. But otherwise, be
"creative": Derive the noise, if you can, from some aspect of your
program design that's irrelevant to the problem domain (e.g. add "Root_"
to "Car"); or in other cases, redundantly express context that might
already be expressed in the module structure (e.g. add "Car_" to
"Steering_Wheel", even though it's already nested in a "Cars" package). 
What other cases do you propose?  With all these various cases, isn't
your scheme really ad hoc?  If you claim it is not ad hoc, can you
articulate a finite number of rules that cover all situations (or at
least a sufficient majority of them)?  The fewer rules the better,
because it means less effort for code writers to apply them, less effort
for code readers to determine which rule has been applied in a
particular situation, less effort for maintainers to keep straight what
they're talking about when they converse about the code, etc.

Personally, I find the form of "creativity" you advocate to be dubious. 
I know of no analog for your scheme in the idioms of any other
programming language.  Why not just settle on a simpler and more
systematic way to introduce the required noise, and have done with it? 
The base/meta distinction is always there, in every case. In fact, it is
the entire reason for this naming dilemma in the first place: We have
objects, and we have their types, and Ada requires that they have
different identifiers. So why not just have a single rule: Consistently
mark every type as such, and reserve the unmarked noun phrase for a
possible variable name.  It's how people speak about the code anyway:
"... and in this method we have an argument 'car' which is an instance
of the 'car' type, which we're using to ..."

> > The old Booch style:
> >
> >   The_Car : Car;
> >
> > also reflects this same base/meta distinction.
> 
> I don't like this convention because it adds noise that the human reader
> is going to mentally parse out anyway, so why not parse it out for him?

But the whole point is that every scheme introduces noise. We are only
quibbling over which form of noise is the least distasteful.  I could as
easily say that the human reader is only interested that the thing is a
"Car", and will just parse out the "Root_" part anyway; or that the
thing is a "Steering_Wheel" from the "Cars" package, and will just parse
out the "Car_" part anyway; so why not just parse out these noise words
for him?

> Better to name the type Car_Type, and the instance Car, becuase the
> object is going to be refered to more often than the type itself.

Yes, I agree that there is a strong argument in favor of putting the
burden of marking upon the type identifier, in order to keep variable
names as short as possible.

However, when you add packages into this naming dilemma, it seems as if
a Booch-like style is still somewhat compelling, as J-P Rosen's style suggests:

  The_Car : Car.Instance;
  The_Steering_Wheel : Steering_Wheel.Instance;

Booch style gives the unmarked noun to the type; Rosen style gives it
instead to the package, and the encapsulated type gets a systematic
noise word.  It would have been nice if this word could have been just "Type":

  The_Car : Car.Type;
  The_Steering_Wheel : Steering_Wheel.Type;

but of course "type" is a reserved word.  (I once toyed with "Tipe", but
thought better of it ... :-)

> A new member of the team I'm on declared a bunch of types (it was a
> binding to a tape drive API) all using the _T convention.  I pointed out
> to him that perhaps a better name would be to include the tape drive in
> the type name, instead of using _T.
> 
> His rebuttal was to ask me how I'd name a color type.  My immediate
> response is, "Well, what is it a color of?"  He said, "Say, a car."  So
> my advice was, name the type Car_Color, not Color_Type.

But you see, you diverted the poor guy off onto a tangent.  What if he
had responded, "Why, it's a color of anything that can _be_ colored, not
just the color of a car.  In short, "Color" is an abstraction all its
own, in a module of its own that is all about colors. Please don't
pollute that abstraction by making it specific to just one particular
usage... Now, this abstraction is about "Color" and only about "Color".
I want to call the package "Color".  But I also want to call the
encapsulated type "Color".  And I want to call the controlling parameter
"Color" in each of my primitve operations, too.  How do I resolve this dilemma?"

> Nor is the object name ad hoc: simply remove the adjective part of the
> name, and keep the noun part.  Just like Mode is an instance of type
> File_Mode, 

I don't think the original designers of Text_IO necessarily completely
thought through all the issues of naming conventions back then.  Isn't
the "File_" part in "File_Mode" just a redundant re-iteration of the
context, since we know that Text_IO is all about text files anyway?  (I
sometimes wish Text_IO had been named Text_Files instead, as this would
have been a more "object-oriented" name; "Text Input/Output" is the
_function_ this package supports, but "Text Files" are the _objects_
this package is _about_.)

On the other hand, let's suppose "File_Mode" is a necessary and
sufficient phrase to express the whole sense of the concept (presumably
within a use-ophilic environment).  Maybe you can get away with dropping
the "File_" adjective for a variable within the package, but can you
always do that outside the package, in all its conceivable clients? 
What if there's a context where you have both a "File_Mode" and some
other kind of mode, say an "Operational_Mode" (e.g., Real vs.
Simulated)?  Then it becomes important to use the complete names for
those concepts, including the "File_" and "Operational_" prefixes, not
just in their type names but also in the variable names.  If we now need
"File_Mode" and "Operational_Mode" as variable names, what should the
types have been called?

You know, I'm not averse to the idea, per se, of dropping prefixed
adjectives when they can be understood from the context.  In fact, in
object-oriented software, it's often the case that a subclass name will
be formed by prefixing an appropriate adjective onto its superclass
name.  A variable of the subclass type can just as easily be thought of
as a variable of the superclass type, so it can be legitimate to just
refer to the variable using the simpler terminology of the superclass type.

I'm just against the idea that dropping prefixed adjectives offers a
general solution to the object/type name dilemma.  One can always come
up with cases where you need to put those adjectives back in, or where
there are no appropriate adjectives to drop in the first place.

> Another simple example: I like to name all scalar types with a dimension
> by using the units in the name, as in
> 
>    Speed : Speed_In_MPH;
>    Length : Length_In_Meters;
> 
> This solves the object-name type-name issue, and removes any ambiguity
> about what units apply to the scalar type.  

As I've pointed out in the past, if it's important to say something in a
type name, there could easily be a case where it's important to say it
in the variable name too:

     Speed_In_MPH : Speed_In_MPH_Type;
     Speed_In_Knots : Speed_In_Knots_Type;
     ...
     Speed_In_Knots := To_Knots(Speed_In_MPH);

> When refering to a literal,
> I like to use a qualified name, as in
> 
>    Set_Speed (Car, Speed => Speed_In_MPH'(10.0));

How about just:

     Set_Speed (Car, Speed_In_MPH => 10.0);

Or perhaps we should consider the word "Speed" to be unnecessary noise:

     MPH : MPH_Type;
     Knots : Knots_Type;
     ...
     Knots := To_Knots(MPH);
     ...
     Set_Speed (Car, MPH => 10.0);

Perhaps "Speed" could be the name of the package that houses the
MPH_Type and Knots_Type, and the To_Knots function, etc...

> > If it was important enough to say, in a type name, that something is a
> > "Car_Steering_Wheel" (as opposed to, perhaps, a "Truck_Steering_Wheel"),
> > then why isn't it also important to say "Car_Steering_Wheel" in the
> > variable name too?  Why arbitrarily lop off the "Car_" part?
> 
> Because you only need to tell me once about the nature of the
> abstraction.  We all know, by reading the _entire_ declaration (not just
> the object name), that we're talking about the steering wheel of a car.
> It _is_ important to tell my that this is a car steering wheel, but you
> only need to tell me once (at declaration time), not tell me again and
> again and again every time I refer to the object.  Because then it would
> just become information the reader is going to mentally parse out.

Unless there's a situation where it becomes important again to
distinguish it as a car's steering wheel, and we find we need to put
that adjective back:

   Car_Steering_Wheel : Car_Steering_Wheel_Type := ...
   Tow_Truck_Steering_Wheel : Tow_Truck_Steering_Wheel_Type := ...
   ...
   -- make the Car simulation physically follow the Tow_Truck simulation:
   Set_Direction (Car_Steering_Wheel, Get_Direction (Tow_Truck_Steering_Wheel));

> > On the other hand, if the "Car_" part is already understood (because the
> > type is already nested inside a "Cars" package), then why bother with
> > the "Car_" part in the first place, in the type name?  Isn't that just
> > noise?
> 
> The Car_ part is there because we need to have a different name for the
> type, because we want to call the object Steering_Wheel.

So basically you're saying the "Car_" part is just noise, right?

> To use _Type really would be noise, because that doesn't tell me
> anything I don't already know (even though it does satisfy the need to
> use a different identifier for the type).

But "Car_" doesn't tell me something I don't already know, either,
right?  I mean, to understand the entire abstraction, we don't just look
at a single _declaration_, we look at the whole _package_ that
encapsulates it, right?  The package name "Cars" already says it all.

> If we know that the object is going to be called Steering_Wheel, and
> that we need a different (and longer) name for the type, then you might
> as well add additional, substantive information about the abstraction
> the type describes.

But what substantive information are you adding that hasn't already been
supplied in other ways?

   with Cars;  -- assume this is written by a use-o-phobe
   ...
      My_Cars_Steering_Wheel : Cars.Car_Steering_Wheel;
                               ^^^^^^^^

Isn't this redundant, and therefore noise?

> (Note that I'm proceeding here under that assumption that types don't
> just float around in space; they're there for a reason, and steering
> wheel abstractions "go with" car abstractions.  As they say, "No object
> is an island.")

Some objects are indeed islands, if we choose to keep them uncoupled to
other objects.  Making abstractions "go with" each other in a single
package increases coupling.  That's a design choice.  The benefits of
cohesion sometimes outweigh the cost of the coupling, but nevertheless
the coupling does incur a cost.  Sometimes the cost of coupling is too
dire, so the right design choice is to separate things out.

> > A naming convention should be systematic, mechanical, predictable and
> > transparent.  That means that it should take NO THOUGHT to apply it, or
> > to interpret the results.
> 
> Be careful not to assume that God decided that this is so.  This
> description of a "good" naming convention is a choice YOU made.
> 
> In fact, I take the exact opposite position, and think that type names
> require careful consideration of the application, the nature of the
> abstraction, and of the intended names of instances.

How is this the "opposite" of what I have been saying? Of course you
should take great care in choosing names that express the problem domain
_concepts_ you wish to address in your program.  There is a great deal
of care, consideration, and indeed creativity that goes into this design
process.  But once you have found names for your concepts, rendering
those concepts into types and variables should be as direct and
straightforward as possible.  If  your programming language forces you
to spend additional creative energy just to cater to its syntactic
foibles, that's a waste.  It would be as much of a waste to spend time
deciding what noise word to add, just for the sake of differentiating a
type name from variable name, as it is to spend time figuring out that:

  if (x = y) ...

really should have been:

  if (x == y) ...

> I'm not suggested that mechanical application of a naming convention
> limits a programmer's creativity.  In fact, the convention I advocate
> often can be applied mechanically.

You seem to be contradicting yourself. How can your convention be
applied mechanically if by definition it requires creativity?  If your
convention can be expressed as a finite set of rules that cover all
situations, then by definition it would require no creativity (beyond
the initial creativity needed to give names to problem domain concepts,
of course).

> Please don't call this the Heaney style - call it the RM style.  My
> argument isn't for a naming convention per se, it's that we should stick
> to the conventions already being used in the language reference manual.

There appear to be many different conventions demonstrated within the
RM, possibly as many different styles as there were designers on the
design teams.  Perhaps the RM can be viewed as a forum where precedents
for various styles were recorded, but I don't think the intent of the RM
was ever to establish some particular coding style as the ideal. Its
primary intent, after all, was to unambiguously specify what the
language is, not to prescribe how it should be used.

Precedent, even long precedent, should not be the only criterion for
chosing a coding style. I would think it's more important to base the
choice on a well-thought out rationale.

As much as we venerate the wise men of ancient days, they really were no
closer to God than we are now.  But we have had more time to think about
it than they did.

-- 
Signature volanSignature =
  new Signature 
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon/TI Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i.*, " +
                    "so loading them throws DontQuoteMeError. :-) " );

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

John G. Volan wrote:

:In fact, what if we even wanted to _preclude_ any
:inheritance?  (In Ada terms, the Car type would be non-tagged.  In Java,
:it would be a final class.  In Eiffel ... not sure of the syntax.)  

    frozen do_something (..) is ..
    ^^^^^^


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[geoff]

In article <ExIqpp.36J@syd.csa.com.au>,
  nospam@thanks.com.au wrote:
> John G. Volan wrote:
>
> :In fact, what if we even wanted to _preclude_ any
> :inheritance?  (In Ada terms, the Car type would be non-tagged.  In Java,
> :it would be a final class.  In Eiffel ... not sure of the syntax.)
>
>     frozen do_something (..) is ..
>     ^^^^^^

Don's Eiffel syntax is correct.

Check out Eric Bezault's annotated ``Eiffel: The Syntax'' web page at:

   http://www.gobo.demon.co.uk/eiffel/syntax/

Just search for ``frozen'' - it appears in ``New_feature'' aggregate.

> Don.
> Don Harrison   donh at syd.csa.com.au

Hope this helps ..

Geoff Eldridge -- ``Eiffel, Back to the Future''

-- geoff@elj.com
-- elj-win32: http://www.elj.com/elj-win32/

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[John Volan]

John G. Volan wrote:
> 
> In fact, what if we even wanted to _preclude_ any
> inheritance?  (In Ada terms, the Car type would be non-tagged...

On second thought, making a type non-tagged doesn't actually preclude
_inheritance_ as such.  In Ada, one may derive a new type from any type,
even from a scalar type such as Integer; the new type technically
inherits all the properties of the parent type, including all its
primitive operations (those declared in the same package spec with the
parent type).  In this sense, even Ada83 supported inheritance.

What a non-tagged type does preclude is type extension, polymorphic
class-wide programming, and dynamic dispatching. But to my knowledge,
there is no mechanism in Ada to selectively prevent type _derivation_.

-- 
Signature volanSignature = 
  new Signature
  ( /*name:      */ "John G. Volan",
    /*employer:  */ "Raytheon Advanced C3I Systems, San Jose",
    /*workEmail: */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail: */ "johnvolan@sprintmail.com",
    /*selfPlug:  */ "Sun Certified Java Programmer",
    /*twoCents:  */ "Java would be even cooler with Ada95's " +
                    "generics, enumerated types, function types, " +
                    "named parameter passing, etc...",
    /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " +
                    "so loading them throws DontQuoteMeError. :-)" );

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> Ada's mechanism is to force the identifiers to be literally different,
> which means either adding some kind of noise word to one or the other,
> or resorting to abbreviation for one or the other. Many react with
> distaste to either prospect, because they recognize both as catering
> to the programming language, and not to the problem domain concept we
> are trying to express. (Remember, the noun phrase in question is
> presumed to be both necessary and sufficient to express the concept.)
> Adding noise seems less obnoxious than abbreviation. So what's the
> least obnoxious noise you can add?

I do this sort of thing too:

   PDW : Pulse_Descriptor_Word;
   
   SOI : Signal_Of_Interest;

   Speed : Speed_In_Knots;

> I hope you recognize that "Root_" is as much a noise word as any
> other, because it caters to the mechanisms of the language rather than
> to the problem domain.  Most OO programmers would find it distasteful
> to mark the class at the top of an inheritance hierarchy this way,
> simply because it was at the top of an inheritance hierarchy.

I'm not sure I understand the argument that you have to "cater to the
language mechanisms."  Under what circumstances do you not have to cater
to the language mechanisms?  

Isn't this what this whole thread is about, how to program in Ada?  We
have to cater to the language mechanisms wrt naming of types (wrt to
anything, actually), so what's the best way to do that?
 
> But this is another tangent irrelevant to P.D.'s simple question, and
> it doesn't address the general case.  What if, for the particular
> problem domain at hand, "CAR" is _not_ intended as the top of an
> inheritance hierarchy?  In fact, what if we even wanted to _preclude_
> any inheritance?  (In Ada terms, the Car type would be non-tagged.  In
> Java, it would be a final class.  In Eiffel ... not sure of the
> syntax.)  In that case, attaching the "Root_" prefix would not only be
> noise, it would be misleading noise.

I would only use "Root_" as a prefix for the root type in a hierarchy of
tagged types.  Under no circumstances would I name a non-tagged type
"Root_".

> So the question remains: All things being equal, what's the least
> noxious noise you can add, that will work even in the most general
> case?

Again, we have different philosophies here.  You argue for a simple
solution ("_Type", I think) that can be applied mechanically, all the
time.  That's fine.  

However, I'm trying my best only use _Type as an indicator of static
polymorphism, and so am advocating a slighly more complicated
convention.  Note that this doesn't preclude mechanical application.
 
> With all these various cases, isn't your scheme really ad hoc?  

I wouldn't describe what I do as ad hoc.  If you've read the code in my
other posts, I'm sure you wouldn't describe it as ad hoc either.  You
might even be tempted to say it's sorta elegent.

> If you claim it is not ad hoc, can you articulate a finite number of
> rules that cover all situations (or at least a sufficient majority of
> them)?

Hmmm.  Let's see.

1) Name the (abstract) root of a hierarchy of tagged types Root_.

One exception (oops, an exception already, on the first bullet!) is if
there's already a good two-part name from the problem domain, use that
instead of Root_.  The classic example is Bank_Account, from which
Checking_Account and Savings_Account derive.

2) Name the type _Type to indicate static polymorphism, ie

   generic
      ...
   package Stacks_Unbounded is

      type Stack_Type is private;


   generic
      ...
   package Stacks_Bounded is
      
      type Stack_Type is private;


3) Name scalar types using the units in the name, ie

   type Heading_In_Degrees is ...;

4) If you often refer to an acronym, then use expanded name as the type, 

   SOI : Signal_Of_Interest;

   PDW : Pulse_Descriptor_Word;

5) Name arrays _Array, and name the array instance the plural:

   type Stack_Item_Array is 
      array (Positive range <>) of Stack_Item;

   Items : Stack_Item_Array;

6) Never ever name a scalar type as a plural

   type Tuner_Ids is range 1 .. 4;  -- you're a bad boy

I makes zero sense to see this

   Id : Tuner_Ids;

since we're only talking about a single object, not an array or set.  So
stick to the singular convention

   type Tuner_Id is range 1 .. 4;

   Id : Tuner_Id;


7) Use an adjective-noun phrase to name the type:

   Tuner_Id
   Character_Glyph
   Bounded_String
   File_Mode


> Why not just settle on a simpler and more systematic way to introduce
> the required noise, and have done with it? 

If you use _Type everywhere, it just becomes noise.  If I have to use an
extra word (I do), then I prefer that the word carry some useful
information.

> So why not just have a single rule: Consistently mark every type as
> such, and reserve the unmarked noun phrase for a possible variable
> name.  

See above.

> But the whole point is that every scheme introduces noise. We are only
> quibbling over which form of noise is the least distasteful.  

No.  The extra verbiage doesn't have to become noise - it can tell me
something useful (like the units).

> I could as easily say that the human reader is only interested that
> the thing is a "Car", and will just parse out the "Root_" part anyway;
> or that the thing is a "Steering_Wheel" from the "Cars" package, and
> will just parse out the "Car_" part anyway; so why not just parse out
> these noise words for him?

Because I wouldn't say that "Car_" is a noise word.
 
> But you see, you diverted the poor guy off onto a tangent.  What if he
> had responded, "Why, it's a color of anything that can _be_ colored,
> not just the color of a car.  In short, "Color" is an abstraction all
> its own, in a module of its own that is all about colors.

No.  I was talking specifically about the color attribute of a car
abstraction.  You have no guarantee that a car abstraction can have all
possible values for color.  Hence, Car_Color.

> I don't think the original designers of Text_IO necessarily completely
> thought through all the issues of naming conventions back then.  Isn't
> the "File_" part in "File_Mode" just a redundant re-iteration of the
> context, since we know that Text_IO is all about text files anyway?
> (I sometimes wish Text_IO had been named Text_Files instead, as this
> would have been a more "object-oriented" name; "Text Input/Output" is
> the _function_ this package supports, but "Text Files" are the
> _objects_ this package is _about_.)

Look at Text_IO as a machine (which it is).  It does more that just
export an ADT - it manages state too (Standard_Input, Standard_Output).

The name Text_Files would be misleading, because Text_IO is not an ADT
package - it's a singleton abstraction that happens to export an ADT.

> On the other hand, let's suppose "File_Mode" is a necessary and
> sufficient phrase to express the whole sense of the concept
> (presumably within a use-ophilic environment).  Maybe you can get away
> with dropping the "File_" adjective for a variable within the package,
> but can you always do that outside the package, in all its conceivable
> clients?  What if there's a context where you have both a "File_Mode"
> and some other kind of mode, say an "Operational_Mode" (e.g., Real vs.
> Simulated)?  Then it becomes important to use the complete names for
> those concepts, including the "File_" and "Operational_" prefixes, not
> just in their type names but also in the variable names.  If we now
> need "File_Mode" and "Operational_Mode" as variable names, what should
> the types have been called?

That does happen sometimes, especially subprogram parameters.  I would
probably do something like this:

  procedure Op
     (File  : in out File_Type;
      FMode : in     File_Mode;
      OMode : in     Operation_Mode);


> You know, I'm not averse to the idea, per se, of dropping prefixed
> adjectives when they can be understood from the context.  

I argue that you have to read the entire declaration to get all the
information.  Sometimes I see guys to this:

   procedure Op (... The_File_Mode : in File_Mode; ...);

but it all seems very redundent.  By reading the entire declaration,
including the type name, that I get all the information I need, but more
concisely, as in

   procedure Op (... Mode : in File_Mode; ...);

> As I've pointed out in the past, if it's important to say something in
> a type name, there could easily be a case where it's important to say
> it in the variable name too:
> 
>      Speed_In_MPH : Speed_In_MPH_Type;
>      Speed_In_Knots : Speed_In_Knots_Type;
>      ...
>      Speed_In_Knots := To_Knots(Speed_In_MPH);


See my point above.

The times when I care about the specific units of speed are only a
subset of all the times I manipulate a speed.  When I really do care
about the units, I just navigate to the declaration, the read units from
the type name.  

You don't need to tell me the units every single time, because I don't
care about units every single time.  And when I don't care, I have to
mentally parse it out.
 
> > When refering to a literal,
> > I like to use a qualified name, as in
> > 
> >    Set_Speed (Car, Speed => Speed_In_MPH'(10.0));
> 
> How about just:
> 
>      Set_Speed (Car, Speed_In_MPH => 10.0);

Then you've made the choice for the client.  I prefer that the client be
able to decide how much verbosity he wants to include at the point of
call.
 
> Or perhaps we should consider the word "Speed" to be unnecessary noise:
> 
>      MPH : MPH_Type;
>      Knots : Knots_Type;
>      ...
>      Knots := To_Knots(MPH);
>      ...
>      Set_Speed (Car, MPH => 10.0);
> 
> Perhaps "Speed" could be the name of the package that houses the
> MPH_Type and Knots_Type, and the To_Knots function, etc...

I don't like this idea.  The characteristics of the supporting type,
such as whether it's fixed or float, the digits of precision, range,
etc, are determined by the larger abstraction.  So I usually place the
attribute types there, with the abstraction they describe.

> Unless there's a situation where it becomes important again to
> distinguish it as a car's steering wheel, and we find we need to put
> that adjective back:
> 
>    Car_Steering_Wheel : Car_Steering_Wheel_Type := ...
>    Tow_Truck_Steering_Wheel : Tow_Truck_Steering_Wheel_Type := ...
>    ...
>    -- make the Car simulation physically 
>    -- follow the Tow_Truck simulation:
>    Set_Direction
       (Car_Steering_Wheel, Get_Direction (Tow_Truck_Steering_Wheel));

Well, I alluded to another technique, and that's to go ahead an use an
abbreviation, as in

   CWheel : Car_Steering_Wheel;
   TWheel : Truck_Steering_Wheel;

for those few times when you have two wheel objects in the same scope.


> > The Car_ part is there because we need to have a different name for the
> > type, because we want to call the object Steering_Wheel.
> 
> So basically you're saying the "Car_" part is just noise, right?

No.  "Car" is never noise.  "Car" is signal.

> But "Car_" doesn't tell me something I don't already know, either,
> right?  I mean, to understand the entire abstraction, we don't just
> look at a single _declaration_, we look at the whole _package_ that
> encapsulates it, right?  The package name "Cars" already says it all.

I'm a use-o-phile.  Therefore I'm not looking at the Cars package when
I'm reading the declaration of an object (because I didn't use an
expanded name).  So the Car_ is telling me something.

> > If we know that the object is going to be called Steering_Wheel, and
> > that we need a different (and longer) name for the type, then you might
> > as well add additional, substantive information about the abstraction
> > the type describes.
> 
> But what substantive information are you adding that hasn't already
> been supplied in other ways?
> 
>    with Cars;  -- assume this is written by a use-o-phobe
>    ...
>       My_Cars_Steering_Wheel : Cars.Car_Steering_Wheel;
>                                ^^^^^^^^
> 
> Isn't this redundant, and therefore noise?

I agree - there is redundancy.  We can resolve that in two ways:

1) use a use, and ditch the expanded name; or

2) don't use a use, and ditch the Car_ prefix.

I choose option 1).

> Some objects are indeed islands, if we choose to keep them uncoupled
> to other objects.  Making abstractions "go with" each other in a
> single package increases coupling.  That's a design choice.

Well, yes and no.  I argue that the color of a car is determined by the
characteristics of the car abstraction, so the declaration of (car)
color goes with the declaration of car.  For example, the factory that
manufactures the cars will only produce a limited number of possible
colors, and the abstraction should capture that feature of the domain.

> Its [the RM] primary intent, after all, was to unambiguously specify
> what the language is, not to prescribe how it should be used.

Well, that's a bit of a stretch.  I'd say just the opposite is true.
 
> Precedent, even long precedent, should not be the only criterion for
> chosing a coding style. I would think it's more important to base the
> choice on a well-thought out rationale.

Agreed.

Re: Naming of Tagged Types and Associated Packages

[Tucker Taft]

Matthew Heaney (matthew_heaney@acm.org) wrote:

: "John G. Volan" <johnvolan@sprintmail.com> writes:

: > Ada's mechanism is to force the identifiers to be literally different,
: > which means either adding some kind of noise word to one or the other,
: > or resorting to abbreviation for one or the other. 
: > ...

: I do this sort of thing too:

:    PDW : Pulse_Descriptor_Word;
:    
:    SOI : Signal_Of_Interest;

:    Speed : Speed_In_Knots;

A better choice for object names is often something that indicates
the specific role the object plays, rather than a name that simply echos
its type name.  Presumably there is more than one object of a given
type in existence.  The names ought to distinguish these objects by
hinting to the reader what they are used for.  For example,
an object of type  "Speed_In_Knots" is presumably the speed for
some particular other entity.  Presuming that that other entity has
a meaningful name, then its speed might be named "<entity>_Speed".
Prepositions like "From" or "To", qualifiers like "Source" and "Target"
or "Next" and "Prev", etc., often are better than just names that
parrot the type.

Remember that every name is a chance to communicate something of 
interest to the reader.  Make every name count (sounds like bidding
in the game of "Bridge" -- "make every bid count").

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Tucker Taft wrote:
> 
> A better choice for object names is often something that indicates
> the specific role the object plays, rather than a name that simply echos
> its type name.  
...
> Prepositions like "From" or "To", qualifiers like "Source" and "Target"
> or "Next" and "Prev", etc., often are better than just names that
> parrot the type.
> 
> Remember that every name is a chance to communicate something of
> interest to the reader.  Make every name count (sounds like bidding
> in the game of "Bridge" -- "make every bid count").

Yes, role names (particularly role names on logical associations a la
UML) are a fertile source of variable names (especially names for object
attributes -- record components, in Ada terms).  When an analysis of the
problem domain provides such names, they should of course be used to
advantage. 

Borrowing an Eiffel example from OOSC2 (Meyer):

    class PERSON feature
        ...
        spouse: PERSON
        landlord: PERSON
        ...
    end

and adapting it to Ada:

    type Person_Type is ... tagged ... private;
    type Person_Access_Type is access all Person_Type'Class;
    ...
    type Person_Type is ... tagged 
      record
        ...
        Spouse   : Person_Access_Type;
        Landlord : Person_Access_Type;
        ...
      end record;

we can see that, in this case, the attribute names do not need to
"parrot" the type name. 

However, many times the most appropriate role name turns out to be
exactly the same term used for the type name itself, and so the
type/object name-clash reasserts itself.  

For instance, going back to our (now quite moldy) example of the "color"
of a "car", here in Eiffel:

    class CAR feature
        ...
        color: COLOR
        ...
    end

    ... -- Usage:
        car: CAR
        ... car.color ...
        
and here in Ada: 

    type Car_Type is ...
      record
        Color : Color_Type;
      end record;

    ... -- Usage:
        Car : Car_Type;
        ... Car.Color ...
 
The attribute in this case is an instance of the "color" type.  It plays
the role of being the "color" of a "car".  Calling it anything else
("paintjob"?) :-) would seem contrived.

> Presumably there is more than one object of a given
> type in existence.  

In "existence", perhaps, but not necessarily in a given scope ...

> The names ought to distinguish these objects by
> hinting to the reader what they are used for.  

This is true when these objects are in a scope where their
distinguishing roles need to be highlighted.  But in building the
abstractions for our types, we often encounter objects in contexts where
any specific role has been abstracted away:

    package Persons is

      type Person_Type is ...

      function Get_Name (Person : in Person_Type) return String;
      ...
    end Persons;

What other "role" is the person in the Get_Name function playing, other
than simply being the person whose name we wish to retrieve?  Yes, we
know that some actual parameters passed into this formal parameter may
turn out to play specific roles such as "spouse" or "landlord" or
"employee", but that is irrelevant at this level of abstraction. 

> For example,
> an object of type  "Speed_In_Knots" is presumably the speed for
> some particular other entity.  Presuming that that other entity has
> a meaningful name, then its speed might be named "<entity>_Speed".

Are you suggesting this sort of redundancy:

    type Car is ...
      record
        ...
        Car_Color : Color;
        Car_Speed : Speed_In_Knots;
        ...
      end record;

    ... -- Usage:
        Some_Car : Car;
        ... Some_Car.Car_Color ... 
        ... Some_Car.Car_Speed ...
                 ^^^^^^^  
-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> > For example,
> > an object of type  "Speed_In_Knots" is presumably the speed for
> > some particular other entity.  Presuming that that other entity has
> > a meaningful name, then its speed might be named "<entity>_Speed".
> 
> Are you suggesting this sort of redundancy:
> 
>     type Car is ...
>       record
>         ...
>         Car_Color : Color;
>         Car_Speed : Speed_In_Knots;
>         ...
>       end record;
> 
>     ... -- Usage:
>         Some_Car : Car;
>         ... Some_Car.Car_Color ... 
>         ... Some_Car.Car_Speed ...

Your example illustrates why it's probably better to name scalar types
with both qualifier and units:

   type Car_Color is ...;

   type Car_Speed_In_MPH is ...;

   type Car_Type is 
     record
        Speed : Car_Speed_In_MPH;
        Color : Car_Color;
        ...
     end record;

   Car : Car_Type;

   ... Car.Speed ...
   ... Car.Color ...

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > With all these various cases, isn't your scheme really ad hoc?
> 
> I wouldn't describe what I do as ad hoc.  If you've read the code in my
> other posts, I'm sure you wouldn't describe it as ad hoc either.  You
> might even be tempted to say it's sorta elegent.

I did read your posts, and I saw your code examples.  To me, personally,
your style strikes me as ad-hoc.  I've already given rationales for why
I feel that way, a couple of times now.  I guess we'll just have to
agree to disagree.

> > If you claim it is not ad hoc, can you articulate a finite number of
> > rules that cover all situations (or at least a sufficient majority of
> > them)?
> 
> Hmmm.  Let's see.
> 
> 1) Name the (abstract) root of a hierarchy of tagged types Root_.
> 
> One exception (oops, an exception already, on the first bullet!) 

And from that one would conclude ... what? ;-)

> is if
> there's already a good two-part name from the problem domain, use that
> instead of Root_.  The classic example is Bank_Account, from which
> Checking_Account and Savings_Account derive.

"Bank_Account" is a good term because it comes straight from the
terminology of the problem domain.  "Root_Account" is bad because it
embeds an implementation detail (the fact that this type happens to be
at the root of an inheritance hierarchy) as part of a name.  If that
design decision should change and a different implementation scheme were
applied, the name would suddenly become inappropriate -- even though the
entity it denoted was still the same conceptual notion from the problem
domain.  

For instance, suppose you started with "Bank_Account" as the root of
your hierarchy, but later expanded the application to include other
kinds of accounts, such as "Mutual_Fund_Account", etc.  You might have a
need for an even more general notion of "Account" that would cover all
kinds of accounts. This "Account" type would become the new root of the
hierarchy, and "Bank_Account" as well as "Mutual_Fund_Account", etc.,
would now inherit from it.

But if all along you'd been using the name "Root_Account" instead of
"Bank_Account", you suddenly have to change the name to something else.

Furthermore, who says Checking_Account and Savings_Account aren't
themselves the roots of their own sub-hierarchies?  Here, you would
probably say that "Root_" is unnecessary because these types already
have expendable adjective prefixes you can drop.  I would say "Root_"
was unnecessary in the first place.

> 2) Name the type _Type to indicate static polymorphism, ie
> 
>    generic
>       ...
>    package Stacks_Unbounded is
> 
>       type Stack_Type is private;
> 
>    generic
>       ...
>    package Stacks_Bounded is
> 
>       type Stack_Type is private;

At one point in this discussion I think I might have grokked your notion
of "static polymorphism", but it's gone completely from my head now, and
the thread has evaporated.  Is it that these generic templates provide
alternate implementations of essentially the same interface, but without
having a common parent type that they both inherit from?  Honestly, I
can't understand your rationale for why this property in particular
would make "_Type" a good prefix here, but not for other types.

> 3) Name scalar types using the units in the name, ie
> 
>    type Heading_In_Degrees is ...;

This is worth another post.

> 4) If you often refer to an acronym, then use expanded name as the type,
> 
>    SOI : Signal_Of_Interest;
> 
>    PDW : Pulse_Descriptor_Word;

See my previous post.

> 5) Name arrays _Array, and name the array instance the plural:
> 
>    type Stack_Item_Array is
>       array (Positive range <>) of Stack_Item;
> 
>    Items : Stack_Item_Array;

Here's how I might handle this:

    generic
      type Item_Type is private;
    package Stacks_Bounded is
      type Stack_Type (Capacity : Positive) is ... private;
      ...
    private
      type Items_Type is
        array (Positive range <>) of Item_Type;
      type Stack_Type (Capacity : Positive) is ...
         record
           Top   : Natural := 0;
           Items : Items_Type;
         end record;
     end Stacks_Bounded;
             

> 6) Never ever name a scalar type as a plural
> 
>    type Tuner_Ids is range 1 .. 4;  -- you're a bad boy

> I makes zero sense to see this
> 
>    Id : Tuner_Ids;

Well, this is one restriction I can agree on!

     type Tuner_Id_Type is range 1 .. 4; -- no plurals!

As I've said before, I don't really object to dropping a prefix when the
context will let you get away with it:

     Id : Tuner_Id_Type;

But my point is that you cannot in general rely on that. Sooner or later
you'll run into a context where the prefix has to be put back:

     Tuner_Id     : Tuner_Id_Type;
     Amplifier_Id : Amplifier_Id_Type;

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

John G. Volan wrote:
> 
>     generic
>       type Item_Type is private;
>     package Stacks_Bounded is
>       type Stack_Type (Capacity : Positive) is ... private;
>       ...
>     private
>       type Items_Type is
>         array (Positive range <>) of Item_Type;
>       type Stack_Type (Capacity : Positive) is ...
>          record
>            Top   : Natural := 0;
>            Items : Items_Type;

             -- Woops! Of course, that should be:
             Items : Items_Type (1 .. Capacity);

>          end record;
>      end Stacks_Bounded;

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> >     generic
> >       type Item_Type is private;
> >     package Stacks_Bounded is
> >       type Stack_Type (Capacity : Positive) is ... private;
> >       ...
> >     private
> >       type Items_Type is
> >         array (Positive range <>) of Item_Type;
> >       type Stack_Type (Capacity : Positive) is ...
> >          record
> >            Top   : Natural := 0;
> >            Items : Items_Type;
> 
>              -- Woops! Of course, that should be:
>              Items : Items_Type (1 .. Capacity);
> 
> >          end record;
> >      end Stacks_Bounded;
> 

The reasons for using a generic formal object as the size vs passing it
in as a discriminant are explicated in the Ada95 Rationale.

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> > 2) Name the type _Type to indicate static polymorphism, ie
> > 
> >    generic
> >       ...
> >    package Stacks_Unbounded is
> > 
> >       type Stack_Type is private;
> > 
> >    generic
> >       ...
> >    package Stacks_Bounded is
> > 
> >       type Stack_Type is private;
> 
> At one point in this discussion I think I might have grokked your notion
> of "static polymorphism", but it's gone completely from my head now, and
> the thread has evaporated.  Is it that these generic templates provide
> alternate implementations of essentially the same interface, but without
> having a common parent type that they both inherit from?  Honestly, I
> can't understand your rationale for why this property in particular
> would make "_Type" a good prefix here, but not for other types.

Because this is the style used in the RM.

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > But you see, you diverted the poor guy off onto a tangent.  What if he
> > had responded, "Why, it's a color of anything that can _be_ colored,
> > not just the color of a car.  In short, "Color" is an abstraction all
> > its own, in a module of its own that is all about colors.
> 
> No.  I was talking specifically about the color attribute of a car
> abstraction.  You have no guarantee that a car abstraction can have all
> possible values for color.  Hence, Car_Color.

Look, I provided you with one puzzle to solve, but you insist on solving
a different one, one that's easier for you to fit into your scheme. 
Okay, fine, but how about solving my puzzle, too?  What if  -- what if
-- you were presented with a problem domain where there are cars, and
there are colors, and there are other things that can have colors, and
any car can get any of the colors?  For me, if I were coding in Ada, it
would be simple:

    with Percentages; use Percentages;
    package Colors is
      type Color_Type is ... private;
      ...
      function Make_Color
         (Red_Percentage   : Percentage_Type;
          Green_Percentage : Percentage_Type;
          Blue_Percentage  : Percentage_Type) return Color_Type;
      ...
      Red   : constant Color_Type;
      Green : constant Color_Type;
      Blue  : constant Color_Type;
      White : constant Color_Type;
      Black : constant Color_Type;
      ...
    end Colors;


    with Colors; use Colors;
    ...
    package Cars is
      type Car_Type is ... private;
      ...
      function Get_Color (Car : in Car_Type) return Color_Type;
      procedure Paint (Car   : in out Car_Type;
                       Color : in     Color_Type);
      ...
    private
      type Car_Type is ...
        record
          ...
          Color : Color_Type;
          ...
        end record;
    end Cars;


    package body Cars is
      ...
      function Get_Color (Car : in Car_Type) return Color_Type is
      begin
        return Car.Color;
      end Get_Color;

      procedure Paint (Car   : in out Car_Type;
                       Color : in     Color_Type) is
      begin
        ...
        Car.Color := Color;
        ...
      end Paint;
      ...
    end Cars;


    -- Usage:
    with Cars; use Cars;
    with Colors; use Colors;
    ...
      Car : Car_Type;
      ...
      Paint (Car, Color => Blue);
      ...


In Java, it would be even simpler:


   public class Color {

       public Color(Percentage redPercentage,
                    Percentage greenPercentage,
                    Percentage bluePercentage)
       {
           ...
       }

       public static final Color RED   = ... ;
       public static final Color GREEN = ... ;
       public static final Color BLUE  = ... ;
       public static final Color WHITE = ... ;
       public static final Color BLACK = ... ;
       ...
   }


   public class Car {

       private Color color;

       public Color getColor() {
           return color;
       }

       public void paint (Color newColor) {
           ...
           color = newColor;
           ...
       }
       ...
    }


    // Usage:
        ...
        Car car = new Car(...);
        ...
        car.paint(Color.BLUE);
        ...

And in Eiffel it would also be simpler:

    expanded class COLOR creation
        make
    feature {NONE}
        make (redPercentage:   PERCENTAGE;
              greenPercentage: PERCENTAGE;
              bluePercentage:  PERCENTAGE) is
            do
                ...
            end
        ...
    end -- class COLOR


    class COLOR_CONSTANTS feature
        ...
        Red:   COLOR is once ... end
        Green: COLOR is once ... end
        Blue:  COLOR is once ... end
        White: COLOR is once ... end
        Black: COLOR is once ... end
        ...
    end -- class COLOR_CONSTANTS


    class CAR creation
        make
    feature
        ...
        color: COLOR
            -- note: no need for a get_color function, clients 
            -- already see attributes as functions (read-only)
            -- due to principle of Uniform Access

        paint (new_color: COLOR) is
            do
                ...
                color := new_color
                ...
            end
        ...
    feature {NONE}
        make (...) is
            do
                ...
            end
    end -- class CAR


    -- Usage:
    ...
    inherit COLOR_CONSTANTS
        ...
        car: CAR;
        ...
        !!car.make(...)
        ...
        car.paint(Blue)
        ...

Now, Matt, given the above, would you still insist that there had to be
a "Car_Color" type somewhere?

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> Look, I provided you with one puzzle to solve, but you insist on solving
> a different one, one that's easier for you to fit into your scheme. 
> Okay, fine, but how about solving my puzzle, too?  What if  -- what if
> -- you were presented with a problem domain where there are cars, and
> there are colors, and there are other things that can have colors, and
> any car can get any of the colors?  For me, if I were coding in Ada, it
> would be simple:

I don't accept your argument, because I don't accept your premise.

I can only speak from my own experience.  And from my own experience,
color types, and speed types, and heading types, don't exist
independently of higher level abstractions, like cars, and targets, and
airframes, and ownships, etc.

If you have a compelling need to declare an enumerated color type (say),
for use by multiple abstractions, then go ahead and name it Color_Type:

package Color_Types is

   type Color_Type is (...);

end Color_Types;

My philosophy is to use the name _Type only as a last resort, as it has
a sort of generic quality to it.  That sometimes turns out to be useful,
as in the example above.  Some guys name generic formal types _Type, for
exactly that reason.

But if I'm implementing a car abstraction that had a color attribute,
then I would name the color type Car_Color.

You point out a problem with this scheme, and that is if there are two
color objects in the same scope.  You correctly observed that my use of
an abbreviation in that case wouldn't be necessary if I had used the
name _Type.

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > Look, I provided you with one puzzle to solve, but you insist on solving
> > a different one, one that's easier for you to fit into your scheme.
> > Okay, fine, but how about solving my puzzle, too?  What if  -- what if
> > -- you were presented with a problem domain where there are cars, and
> > there are colors, and there are other things that can have colors, and
> > any car can get any of the colors?  For me, if I were coding in Ada, it
> > would be simple:
> 
> I don't accept your argument, because I don't accept your premise.
> 
> I can only speak from my own experience.  And from my own experience,
> color types, and speed types, and heading types, don't exist
> independently of higher level abstractions, like cars, and targets, and
> airframes, and ownships, etc.

Alright then, if "secondary" abstractions just keep distracting you from
my point, forget about the secondary abstractions.  What about the
primary abstractions themselves?  My point is about primary abstractions
anyway.  

It may be comforting to you to keep focusing on secondary abstractions,
because your naming scheme works so well for them: The primary
abstractions they are attached to are such a convenient source for the
expendable prefix you need.  But where do you get an expendable prefix
for a primary abstraction?  I was trying to get you to see that your
scheme was ad-hoc, because there really is no general source of
expendable prefixes for primary abstractions.

To demonstrate the dilemma, I was hoping, for the sake of example, that
you'd be able to treat the notion of "color" as a primary abstraction (I
even sketched how it might look as a private type), but for some reason
you seem stuck on "color" being just a secondary abstraction
(implemented as a scalar type).  If it will help, try a different example:

    with Patients; use Patients;
    package Doctors is

      type Doctor_Type is ... private;

      procedure Treat_Patient
        (Doctor  : in out Doctor_Type;
         Patient : in out Patient_Type);

      procedure Bill_Patient
        (Doctor  : in out Doctor_Type;
         Patient : in out Patient_Type);
      ...
    end Doctors;

Here, the problem-domain concepts of "doctor" and "patient" are treated
as primary abstractions, each implemented as a private type encapsulated
in a separate package.  Cohen naming style has been systematically
applied: From the problem-domain terminology of "doctor" and "patient",
the package names have been derived by taking the plurals, and the type
names have been derived by appending "_Type".  This leaves the simple
form of the terms free to use as nondescript instance names, such as the
formal parameters of procedures like Treat_Patient and Bill_Patient.

Starting from the same problem domain concepts, "doctor" and "patient",
what names would your technique generate for the packages, the types,
and the nondescript formal parameters? 

> If you have a compelling need to declare an enumerated color type (say),
> for use by multiple abstractions, then go ahead and name it Color_Type:
> 
> package Color_Types is
> 
>    type Color_Type is (...);
>
> end Color_Types;

See above, and see my previous post: I had Color_Type as private type,
not just an enumerated type.  It had operations allowing a color to be
formed from percentages of red, green, and blue components.  That's a
significant enough abstraction to warrant its own package, and you
wouldn't want to repeat all that code in client packages like "Cars".

> My philosophy is to use the name _Type only as a last resort, as it has
> a sort of generic quality to it.  That sometimes turns out to be useful,
> as in the example above.  Some guys name generic formal types _Type, for
> exactly that reason.

> But if I'm implementing a car abstraction that had a color attribute,
> then I would name the color type Car_Color.
> 
> You point out a problem with this scheme, and that is if there are two
> color objects in the same scope.  You correctly observed that my use of
> an abbreviation in that case wouldn't be necessary if I had used the
> name _Type.

No, the example was two different _types_ used in the same context:
File_Mode and Operational_Mode; which, after jettisoning their
"expendable" prefixes, yield the same variable name: Mode.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> My philosophy is to use the name _Type only as a last resort, as it has
> a sort of generic quality to it.  

Funny, I'd say its precisely this quality that should make _Type the
*first* resort! :-)  It's so generally applicable as a type-marking
suffix one might as well use it everywhere...

> That sometimes turns out to be useful,
> as in the example above.  Some guys name generic formal types _Type, for
> exactly that reason.

I'd say, don't treat generic formal types any differently than normal
types: Mark 'em all with "_Type"!  One nice feature of Cohen style is
that it results in a clearly-readable distinction between generic formal
parameter passing and subprogram parameter passing, which otherwise are
syntactically identical (in Ada):

  -- Generic formal parameter passing:
  package Doctor_Lists is new
    Lists (Item_Type => Doctors.Doctor_Type);
           -- it's clear that the parameter 
           -- being passed is a _type_
  ...
  Doctor_List : Doctors_Lists.List_Type;
  Doctor : Doctors.Doctor_Type;
  ...
  Doctor_Lists.Append (List => Doctor_List, Item => Doctor);
                       -- it's clear that the parameters
                       -- being passed are _objects_

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Sun, 6 Sep 1998, John G. Volan wrote:
> Matthew Heaney wrote:
> > 
> > My philosophy is to use the name _Type only as a last resort, as it has
> > a sort of generic quality to it.  
> 
> Funny, I'd say its precisely this quality that should make _Type the
> *first* resort! :-)  It's so generally applicable as a type-marking
> suffix one might as well use it everywhere...

Exactly my line of thinking too :-|. This is one of the reason's I like
the Dylan convention of delimiting type names with angle brackets; this 
convention has the pleasing (to me) effect of making type names look very 
different from other lexical items.

-- Brian

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Brian Rogoff wrote:
> 
> On Sun, 6 Sep 1998, John G. Volan wrote:
> > Matthew Heaney wrote:
> > >
> > > My philosophy is to use the name _Type only as a last resort, as it has
> > > a sort of generic quality to it.
> >
> > Funny, I'd say its precisely this quality that should make _Type the
> > *first* resort! :-)  It's so generally applicable as a type-marking
> > suffix one might as well use it everywhere...
> 
> Exactly my line of thinking too :-|. This is one of the reason's I like
> the Dylan convention of delimiting type names with angle brackets; this
> convention has the pleasing (to me) effect of making type names look very
> different from other lexical items.

I assume this makes it possible to do something like:

   Car   : <Car>;
   Color : <Color>;

In other words, the Dylan convention yields what are effectively two
completely disjoint namespaces for object names and type names. The
marking clearly indicates which namespace a given identifier belongs to.
But except for the marking, identifiers in the two namespaces could be identical.

Compare that with the style convention in Eiffel,  where all-uppercase
is used for type names and all-lowercase (or mixed case) is used for
entity names. e.g.

   car   : CAR
   color : COLOR

In this case, the language really does maintain two dijoint namespaces.
The capitalization scheme is just a convention; Eiffel is actually
case-insensitive, but it uses syntactic context to decide which
namespace to use at any given point.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Brian Rogoff]

On Sun, 6 Sep 1998, John G. Volan wrote:
> Brian Rogoff wrote:
> > On Sun, 6 Sep 1998, John G. Volan wrote:
> > > Funny, I'd say its precisely this quality that should make _Type the
> > > *first* resort! :-)  It's so generally applicable as a type-marking
> > > suffix one might as well use it everywhere...
> > 
> > Exactly my line of thinking too :-|. This is one of the reason's I like
> > the Dylan convention of delimiting type names with angle brackets; this
> > convention has the pleasing (to me) effect of making type names look very
> > different from other lexical items.
> 
> I assume this makes it possible to do something like:
> 
>    Car   : <Car>;
>    Color : <Color>;
> 
> In other words, the Dylan convention yields what are effectively two
> completely disjoint namespaces for object names and type names. The
> marking clearly indicates which namespace a given identifier belongs to.
> But except for the marking, identifiers in the two namespaces could be 
> identical.

Exactly. Its a convention, the same one as the _Type convention for Ada, 
except that it is used consistently in the base Dylan language, and I 
personally find it easier to read than _Type. I'm aware that opinions will 
differ. 

> Compare that with the style convention in Eiffel,  where all-uppercase
> is used for type names and all-lowercase (or mixed case) is used for
> entity names. e.g.
> 
>    car   : CAR
>    color : COLOR
> 
> In this case, the language really does maintain two dijoint namespaces.
> The capitalization scheme is just a convention; Eiffel is actually
> case-insensitive, but it uses syntactic context to decide which
> namespace to use at any given point.

I don't like this, but I imagine if I spend every day for a few days
staring at consistently formatted Eiffel code I'd come around. However, 
I'd also suggest that some amount of type inference in the language would
remove some of the burden of name invention, and thats generally a good 
thing.

No comment on your new signature ;-).

-- Brian

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Brian Rogoff wrote:
> 
> No comment on your new signature ;-).

Heh, there's something to be said about being able to express a
disclaimer as something more than a comment ... :-)

-- 
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
>    disclaimer: not (opinion implies employer.opinion)
> end -- class JOHN_VOLAN_SIGNATURE

That Ada doesn't have an implication operator is a real bummer.  It
makes it difficult to state a postcondition:

not (opinion implies employer.opinion) =
not (not opinion or employer.opinion) =
opinion and not employer.opinion

I would say the form using implication is more clear, eh?

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

[I just noticed that Matthew picked up this thread again over here on
comp.lang.ada. There's a lot to comment on, so I may need more than one post.]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > Ada's mechanism is to force the identifiers to be literally different,
> > which means either adding some kind of noise word to one or the other,
> > or resorting to abbreviation for one or the other. Many react with
> > distaste to either prospect, because they recognize both as catering
> > to the programming language, and not to the problem domain concept we
> > are trying to express. (Remember, the noun phrase in question is
> > presumed to be both necessary and sufficient to express the concept.)
> > Adding noise seems less obnoxious than abbreviation. So what's the
> > least obnoxious noise you can add?
> 
> I do this sort of thing too:
> 
>    PDW : Pulse_Descriptor_Word;
> 
>    SOI : Signal_Of_Interest;

I thought one assumption in this discussion was that we were trying to find
schemes that would allow us to avoid abbreviations.  But if abbreviations
were fair game, then there would never have been an issue:

     type Color is ...

     type Car is record
       C : Color;
       ...
     end record;

     C : Car; 

     ... C.C ... -- so nice and readable! :-)

However, I think we can do a lot better than that ...

[...snip...]

> > On the other hand, let's suppose "File_Mode" is a necessary and
> > sufficient phrase to express the whole sense of the concept
> > (presumably within a use-ophilic environment).  Maybe you can get away
> > with dropping the "File_" adjective for a variable within the package,
> > but can you always do that outside the package, in all its conceivable
> > clients?  What if there's a context where you have both a "File_Mode"
> > and some other kind of mode, say an "Operational_Mode" (e.g., Real vs.
> > Simulated)?  Then it becomes important to use the complete names for
> > those concepts, including the "File_" and "Operational_" prefixes, not
> > just in their type names but also in the variable names.  If we now
> > need "File_Mode" and "Operational_Mode" as variable names, what should
> > the types have been called?
> 
> That does happen sometimes, especially subprogram parameters.  I would
> probably do something like this:
> 
>   procedure Op
>      (File  : in out File_Type;
>       FMode : in     File_Mode;
>       OMode : in     Operation_Mode);

So when push comes to shove, you advocate that we give up on English and
resort to ad-hoc abbreviations?  Why "FMode" and "OMode", particularly? 
Why not "Filmod" and "Opmod"? or "FileM" and OperatM"?  Indeed, why not
just "FM" and "OM"?

When I code, one principle I strive for is "No Synonyms":  As much as
possible, I'll try to use exactly one term to designate one concept. 
When that term is expressed in full English words (e.g., "File_Mode"),
it's not too hard to keep to a single spelling.  But once you start
abbreviating, it's too easy to proliferate a lot of alternate
abbreviations for the same thing, even in the same code module!  I've
seen it happen, and it's not pretty.

You can say it's a matter of taste, but a lot of what we've been
discussion is just taste.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"John G. Volan" <johnvolan@sprintmail.com> writes:

> > I do this sort of thing too:
> > 
> >    PDW : Pulse_Descriptor_Word;
> > 
> >    SOI : Signal_Of_Interest;
> 
> I thought one assumption in this discussion was that we were trying to find
> schemes that would allow us to avoid abbreviations.  But if abbreviations
> were fair game, then there would never have been an issue:

Those happen to be the terms people on our project really use to refer
to the entity.  "What was the value of the pee dee double-yew?"  "What's
the ess oh eye?"

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > > I do this sort of thing too:
> > >
> > >    PDW : Pulse_Descriptor_Word;
> > >
> > >    SOI : Signal_Of_Interest;
> >
> > I thought one assumption in this discussion was that we were trying to find
> > schemes that would allow us to avoid abbreviations.  But if abbreviations
> > were fair game, then there would never have been an issue:
> 
> Those happen to be the terms people on our project really use to refer
> to the entity.  "What was the value of the pee dee double-yew?"  "What's
> the ess oh eye?"

Abbreviations per se are not evil. If an abbreviation or acronym is
well-known and well-established in a given problem domain (e.g. your PDW
or SOI), then it's a legitimate candidate for the name of a program
entity.  

Rather, it's _ad-hoc_ abbreviations that are evil, abbreviations that a
programmer invents on the spot for his own convenience but without any
basis from the problem domain.  (For instance, your "FMode" and "OMode"
for "File_Mode" and "Operational_Mode", when you were forced to
disambiguate "Mode" in a specific context.)

But if well-established abbreviations like PDW and SOI are good names,
then they're good not just as variable names, but also as type names --
and we're back to square one!

The problem with using a legitimate abbreviation like SOI _and_ the
fully-spelled out term Signal_Of_Interest within the same program is
that these verge on being synonyms of each other, and this might be
construed as a violation of the "No Synonyms" principle. (Whether you
want to subscribe to that principle, is of course up to you.) What this
principle seeks to avoid is situations like this:

    Position : Location;
    Direction : Azimuth;
    Point : Vertex;

It would be better either to have:

    Position : Position_Type;
    Direction : Direction_Type;
    Point : Point_Type;

or this would be okay:

    Location : Location_Type;
    Azimuth : Azimuth_Type;
    Vertex : Vertex_Type;

In other words, for each concept from your problem domain, use just one
term for it in your program text.

According to that principle, the following would be okay:

    PDW : PDW_Type;
    SOI : SOI_Type;
    -- as long as these acronyms were documented in the official
    -- project acronym list and the programmers were trained

or this would be okay:

    Pulse_Descriptor_Word : Pulse_Descriptor_Word_Type;
    Signal_Of_Interest    : Signal_Of_Interest_Type;

but NOT this:

    PDW : Pulse_Descriptor_Word;
    SOI : Signal_Of_Interest;

Of course, that's a pretty strict reading of the No Synonyms principle.
Is an acronym _really_ a distinct synonym for the spelled-out term?  One
could argue that it's just an alternate _form_ for that term, so why not
allow both? 

The problem is that this is a slippery slope. If programmers start out
with supposedly legitimate cases like "SOI: Signal_Of_Interest" and get
used to that as a pattern, it's just too tempting to slide into ad-hoc
cases like "FM: File_Mode" when the going gets tough.

How do you tell an ad-hoc abbreviation from a legitimate one?  If you
see a given abbreviation on a page, what feature of it will leap out and
tell you whether it's in the approved list or it's something the
programmer made up on the spot?  The answer is, nothing.  Unless you're
an extreme expert on the problem domain (and not all programmers are),
you'd need to go check the list.

Another argument against cases like "SOI: Signal_Of_Interest" is this:
If "SOI" and "Signal_Of_Interest" are just two equally-good forms of the
same term, then why not give the programmer the discretion to choose
_either_ form, anyplace where that term comes up in the program?  In
other words:

    type Signal_Of_Interest_Type is ... ;
    subtype SOI_Type is Signal_Of_Interest_Type;
      -- using a subtype as a "renaming" for a type

And then let each programmer choose either to use

    SOI : SOI_Type;

or to use

    Signal_Of_Interest : Signal_Of_Interest_Type;

at their own discretion.  

Another way of putting it is: Why lock up the spell-out form of a term
like "Signal_Of_Interest" as a type name?  That prevents programmers
from using it as a variable name when they want to.  You're essentially
_forcing_ them to use the abbreviation when they want to name their variables.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

[Apologies if this turns out to be a re-post. Having some problems with
my newsfeed...]

Matthew Heaney wrote:
> 
> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > > I do this sort of thing too:
> > >
> > >    PDW : Pulse_Descriptor_Word;
> > >
> > >    SOI : Signal_Of_Interest;
> >
> > I thought one assumption in this discussion was that we were trying to find
> > schemes that would allow us to avoid abbreviations.  But if abbreviations
> > were fair game, then there would never have been an issue:
> 
> Those happen to be the terms people on our project really use to refer
> to the entity.  "What was the value of the pee dee double-yew?"  "What's
> the ess oh eye?"

Abbreviations per se are not evil. If an abbreviation or acronym is
well-known and well-established in a given problem domain (e.g. your PDW
or SOI), then it's a legitimate candidate for the name of a program
entity.  

Rather, it's _ad-hoc_ abbreviations that are evil, abbreviations that a
programmer invents on the spot for his own convenience but without any
basis from the problem domain.  (For instance, your "FMode" and "OMode"
for "File_Mode" and "Operational_Mode", when you were forced to
disambiguate "Mode" in a specific context.)

But if well-established abbreviations like PDW and SOI are good names,
then they're good not just as variable names, but also as type names --
and we're back to square one!

The problem with using a legitimate abbreviation like SOI _and_ the
fully-spelled out term Signal_Of_Interest within the same program is
that these verge on being synonyms of each other, and this might be
construed as a violation of the "No Synonyms" principle. (Whether you
want to subscribe to that principle, is of course up to you.) What this
principle seeks to avoid is situations like this:

    Position : Location;
    Direction : Azimuth;
    Point : Vertex;

It would be better either to have:

    Position : Position_Type;
    Direction : Direction_Type;
    Point : Point_Type;

or this would be okay:

    Location : Location_Type;
    Azimuth : Azimuth_Type;
    Vertex : Vertex_Type;

In other words, for each concept from your problem domain, use just one
term for it in your program text.

According to that principle, the following would be okay:

    PDW : PDW_Type;
    SOI : SOI_Type;
    -- as long as these acronyms were documented in the official
    -- project acronym list and the programmers were trained

or this would be okay:

    Pulse_Descriptor_Word : Pulse_Descriptor_Word_Type;
    Signal_Of_Interest    : Signal_Of_Interest_Type;

but NOT this:

    PDW : Pulse_Descriptor_Word;
    SOI : Signal_Of_Interest;

Of course, that's a pretty strict reading of the No Synonyms principle.
Is an acronym _really_ a distinct synonym for the spelled-out term?  One
could argue that it's just an alternate _form_ for that term, so why not
allow both? 

The problem is that this is a slippery slope. If programmers start out
with supposedly legitimate cases like "SOI: Signal_Of_Interest" and get
used to that as a pattern, it's just too tempting to slide into ad-hoc
cases like "FM: File_Mode" when the going gets tough.

How do you tell an ad-hoc abbreviation from a legitimate one?  If you
see a given abbreviation on a page, what feature of it will leap out and
tell you whether it's in the approved list or it's something the
programmer made up on the spot?  The answer is, nothing.  Unless you're
an extreme expert on the problem domain (and not all programmers are),
you'd need to go check the list.

Another argument against cases like "SOI: Signal_Of_Interest" is this:
If "SOI" and "Signal_Of_Interest" are just two equally-good forms of the
same term, then why not give the programmer the discretion to choose
_either_ form, anyplace where that term comes up in the program?  In
other words:

    type Signal_Of_Interest_Type is ... ;
    subtype SOI_Type is Signal_Of_Interest_Type;
      -- using a subtype as a "renaming" for a type

And then let each programmer choose either to use

    SOI : SOI_Type;

or to use

    Signal_Of_Interest : Signal_Of_Interest_Type;

at their own discretion.  

Another way of putting it is: Why lock up the spell-out form of a term
like "Signal_Of_Interest" as a type name?  That prevents programmers
from using it as a variable name when they want to.  You're essentially
_forcing_ them to use the abbreviation when they want to name their variables.

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[John G. Volan]

[Cross-posted to comp.lang.eiffel, since I've added Eiffel content]

Matthew Heaney wrote:
>
> "John G. Volan" <johnvolan@sprintmail.com> writes:
>

[...snip...]

> 3) Name scalar types using the units in the name, ie
> 
>    type Heading_In_Degrees is ...; 

[...snip...]

> > As I've pointed out in the past, if it's important to say something in
> > a type name, there could easily be a case where it's important to say
> > it in the variable name too:
> >
> >      Speed_In_MPH : Speed_In_MPH_Type;
> >      Speed_In_Knots : Speed_In_Knots_Type;
> >      ...
> >      Speed_In_Knots := To_Knots(Speed_In_MPH);
> 
> See my point above.
> 
> The times when I care about the specific units of speed are only a
> subset of all the times I manipulate a speed.  When I really do care
> about the units, I just navigate to the declaration, the read units from
> the type name.
> 
> You don't need to tell me the units every single time, because I don't
> care about units every single time.  And when I don't care, I have to
> mentally parse it out.

I'm not saying that such details need to be stated at _all_ times. I can
accept dropping prefixes and suffixes if the context allows, e.g.:

    type Ship_Type is
      record
        Speed : Speed_In_Knots_Type;
        ...
      end record;

    Ship : Ship_Type;

    ... Ship.Speed ... -- we can look up the declaration to remind us of
                       -- the units

I'm merely saying that these suffixes and prefixes may be needed at
_some_ time, when the context forces us to disambiguate things, as in my
example you quoted above.  

If you had to do the above conversion using your naming scheme, how
would you declare the two different "speed" objects?  You rely on being
able to drop a
unit suffix to generate a variable name distinct from the type name. But
in the above situation, these suffixes are needed again to disambiguate
the two variables, which otherwise would have wound up with the same
name according to your scheme.

If your answer is, "Well, I'll just come up with some abbreviations for
the speed in knots variable vs. the speed in mph variable," then I'd
say, okay, you're free to do so, but then you'd have to admit that you
were doing something  ad-hoc.

Remember, the reason we're forced into all these contortions is because
of Ada's case insensitivity, combined with its strict insistence that
type names and variable names share a single namespace (within a given
scope).  In a language that relaxes either of these properties, we don't
have a problem. For instance, in Eiffel we might have:

    expanded class SPEED_IN_MPH   inherit DOUBLE feature ... end
    expanded class SPEED_IN_KPH   inherit DOUBLE feature ... end
    expanded class SPEED_IN_KNOTS inherit DOUBLE feature ... end

    class SHIP feature
        speed: SPEED_IN_KNOTS
        ...
    end -- class SHIP

And the above conversion situation would be something like:

    speed_in_mph: SPEED_IN_MPH;
    speed_in_knots: SPEED_IN_KNOTS;
    ...
    speed_in_knots := to_knots (speed_in_mph)


> > Or perhaps we should consider the word "Speed" to be unnecessary noise:
> >
> >      MPH : MPH_Type;
> >      Knots : Knots_Type;
> >      ...
> >      Knots := To_Knots(MPH);
> >      ...
> >      Set_Speed (Car, MPH => 10.0);
> >
> > Perhaps "Speed" could be the name of the package that houses the
> > MPH_Type and Knots_Type, and the To_Knots function, etc...
> 
> I don't like this idea.  The characteristics of the supporting type,
> such as whether it's fixed or float, the digits of precision, range,
> etc, are determined by the larger abstraction.  So I usually place the
> attribute types there, with the abstraction they describe.

If I'm reading this right, what you're saying is that if an analysis of
the problem domain indicates that a car has a speed in miles per hour,
you'd put a Car_Speed_In_MPH type in the Cars package along with a
<Something>_Car type?

Suppose further analysis of the problem domain indicated that weather
conditions constituted an important abstraction (let's say the system
does fine engine and transmission control to improve traction and fuel
economy in adverse weather).  Then you might have a Wind_Speed_In_MPH
type in a Weather package.

Would these two speed types have no commonality?  Would you be forced to
do a lot of type-conversions to work with them both?  Why couldn't you
just have a single Speed_In_MPH_Type in a common package (regarding
Speeds) that could be shared between the Cars package and the Weather package?

I've often noted that Ada projects tend to proliferate a lot of
unnecessary, redundant representations for the same classes of physical
quantities.  Little attempt is made to standardize on a normalized set
of unit types and accuracies, so you wind up with a lot of complex,
redundant, and hard to maintain conversion code scattered all over the
system.  

Such projects might have benefited greatly if physical quantity types
had been treated as first-class abstractions in their own right, e.g.:

    package Speeds is

      type Speed_Type is private;

      function From_MPH   (MPH   : in Long_Float) return Speed_Type;
      function From_KPH   (KPH   : in Long_Float) return Speed_Type;
      function From_Knots (Knots : in Long_Float) return Speed_Type;
      ...
      function To_MPH   (Speed : in Speed_Type) return Long_Float;
      function To_KPH   (Speed : in Speed_Type) return Long_Float;
      function To_Knots (Speed : in Speed_Type) return Long_Float;
      ...
    private
      type Speed_Type is
        record
          MPH : Long_Float;
            -- arbitrary choice, might be changed 
            -- without affecting the abstraction
        end record;
    end Speeds;

    with Speed_Constants; use Speed_Constants;
    package body Speeds is

      function From_MPH (MPH : in Long_Float) return Speed_Type is
      begin
        return (MPH => MPH);
      end From_MPH;

      function From_KPH (KPH : in Long_Float) return Speed_Type is
      begin
        return (MPH => KPH * KPH_To_MPH);
      end From_KPH;

      function From_Knots (Knots : in Long_Float) return Speed_Type is
      begin
        return (MPH => Knots * Knots_To_MPH);
      end From_Knots;
      ...
      function To_MPH (Speed : in Speed_Type) return Long_Float is
      begin
        return Speed.MPH;
      end To_MPH;

      function To_KPH (Speed : in Speed_Type) return Long_Float is
      begin
        return Speed.MPH * MPH_To_KPH;
      end To_KPH;

      function To_Knots (Speed : in Speed_Type) return Long_Float is
      begin
        return Speed.MPH * MPH_To_Knots;
      end To_Knots;

      ...
    end Speed;
 

Here's a similar rendition in Eiffel:

    expanded class
        SPEED
    inherit
        SPEED_CONSTANTS;
            -- assume provides Mph_to_kph, Kph_to_mph, etc...
        DOUBLE_APPROXIMATION
            -- assume provides comparison functions that account
            -- for numeric inprecision in DOUBLE computations, e.g.:
            -- sufficiently_equal, sufficiently_greater, etc.
            -- Are such functions already available somewhere?
    feature
        mph: DOUBLE
            -- this happens to be the only attribute,
            -- but that is an arbitrary choice. The rest
            -- are conversion functions:

        kph: DOUBLE is
            do
                Result := mph * Mph_to_kph
            end

        knots: DOUBLE is
            do
                Result := mph * Mph_to_knots
            end
        ...

        set_mph (new_mph: DOUBLE) is
            do
                mph := new_mph
            ensure
                sufficiently_equal (mph, new_mph)
            end

        set_kph (new_kph: DOUBLE) is
            do
                mph := new_kph * Kph_to_mph
            ensure
                sufficiently_equal (kph, new_kph)
            end

        set_knots (new_knots: DOUBLE) is
            do
                mph := new_knots * Knots_to_mph
            ensure
                sufficiently_equal (knots, new_knots)
            end

         accelerate (delta_speed: SPEED) is
            do
                mph := mph + delta_speed.mph
            ensure
                sufficiently_equal (mph, mph + delta_speed.mph)
            end
         ...
     invariant
         kph_definition: 
             sufficiently_equal (mph * Mph_to_kph, kph);
         knots_definition:
             sufficiently_equal (mph * Mph_to_knots, knots);
         ...
     end -- class SPEED


An intriguing alternative possibility would be to make SPEED a deferred
class instead (an abstract type in Ada95 parlance):


    deferred class
        SPEED
    inherit
        SPEED_CONSTANTS;
            -- assume provides Mph_to_kph, Kph_to_mph, etc...
        DOUBLE_APPROXIMATION
            -- assume provides comparison functions that account
            -- for numeric inprecision in DOUBLE computations, e.g.:
            -- sufficiently_equal, sufficiently_greater, etc.
            -- Are such functions already available somewhere?
    feature
        mph:   DOUBLE is deferred end
        kph:   DOUBLE is deferred end
        knots: DOUBLE is deferred end
        ...

        set_mph (new_mph: DOUBLE) is
            deferred
            ensure
                sufficiently_equal (mph, new_mph)
            end

        set_kph (new_kph: DOUBLE) is
            deferred
            ensure
                sufficiently_equal (kph, new_kph)
            end

        set_knots (new_knots: DOUBLE) is
            deferred
            ensure
                sufficiently_equal (knots, new_knots)
            end

         accelerate (delta_speed: SPEED) is
            require
                delta_speed_exists: delta_speed /= Void
            deferred
            ensure
                sufficiently_equal (mph, mph + delta_speed.mph)
            end
         ...
     invariant
         kph_definition: 
             sufficiently_equal (mph * Mph_to_kph, kph);
         knots_definition:
             sufficiently_equal (mph * Mph_to_knots, knots);
         ...
     end -- class SPEED


Then, you could have different heirs of this class optimized for
specific units of measure:

     expanded class
         SPEED_IN_MPH
     inherit
         SPEED
     feature
         mph: DOUBLE

         kph: DOUBLE is
             do
                 Result := mph * Mph_to_kph
             end

         knots: DOUBLE is
             do
                 Result := mph * Mph_to_knots
             end
         ...
         accelerate (delta_speed: SPEED) is
             do
                 mph := mph + delta_speed.mph
             end
         ...
     end -- class SPEED_IN_MPH


     expanded class
         SPEED_IN_KPH
     inherit
         SPEED
     feature
         mph: DOUBLE is
             do
                 Result := kph * Kph_to_mph
             end

         kph: DOUBLE

         knots: DOUBLE is
             do
                 Result := kph * Kph_to_knots
             end
         ...
         accelerate (delta_speed: SPEED) is
             do
                 kph := kph + delta_speed.kph
             end
         ...
      end -- end class SPEED_IN_KPH


      ... similarly for SPEED_IN_KNOTS, etc.


Then a class like CAR could have a SPEED attribute that could avail
itself of polymorphism:


      class CAR creation
          make
      feature -- Status report
          speed: SPEED

      feature -- Status setting

          set_speed (new_speed: SPEED) is
              require
                  speed_exists: new_speed /= Void
              do
                  speed := new_speed;
              end
          ...
      feature {NONE} -- Initialization
          make is
              do
                  ...
                  !SPEED_IN_MPH! speed
                      -- default to optimize on miles per hour,
                      -- but can be changed later (via set_speed)
                      -- to optimize on other units                      
                  ...
              end
          ...
      invariant
          speed_exists: speed /= Void
          ...
      end -- class CAR


-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE

Re: Naming of Tagged Types and Associated Packages

[doylep]

In article <m3pveclhna.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
>
> doylep@ecf.toronto.edu writes:
>
> > class CAR
> >
> > feature
> >     steering_wheel : STEERING_WHEEL
> >
> > end
> >
> > What else are you going to call the steering wheel?  A
> > direction_control_device? I think any other name would be contrived.
>
> I usually qualify auxiliary types with the name of the "main" type, so I
> probably would have named the type Car_Steering_Wheel, and the object
> Steering_Wheel.

Doesn't this policy significantly hamper the OO process?  IMHO, OO is about
looking for common abstractions; coming up with one-shot abstractions is far
less conducive to reuse.

Thus, I'd very much prefer calling the class "Steering_wheel" and finding
abstractions common to *all* steering wheels.  Then I could reuse this class
in any application requiring steering wheels.  If a car's steering wheel is
really different, it could be its own subclass.

 -PD

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

nospam@thanks.com.au (Don Harrison) writes:

> I think it's not so much namespaces but the fact that the syntax allows 
> you (and the compiler) to easily differentiate variables (entities in 
> Eiffel parlance) from types.
> 
> Some examples..
> 
> 1) Variable declarations:
> 
>        variable : TYPE
> 
>    The identifier to the left of the colon is recognised as a variable 
>    and the one on the right as a type.

But this is true in Ada too.  The issue in Ada is that once an
identifier appears in a declaration, it can't appear again in the same
declaration.  So the declaration

declare
   File : File;
begin

is illegal in Ada, even though the compiler knows that the identifier
on the left denotes an object, and the identifier on the right a type.

The same is true for function invokations (aka "constructors") that
appear in a declaration.  The declaration

declare
   Top : Integer renames Top (Integer_Stack);
begin

is illegal, because of the name clash between object Top and selector
Top.  That's why I usually name selectors Get_xxx, to avoid namespace
conflicts inside a declaration.  The declaration

declare 
   Top : Integer renames Get_Top (Integer_Stack);
begin

is now legal.


I argue that different names should be used for an object and its type
in a declaraion, in order to prevent namespace clashes.  I don't think
an expanded name (ie P.T) should be used for this purpose.

I make this argument based on a careful reading of the RM.  File_Type is
called that precisely because an object of that type will most likely be
called File.

Had the designers intended for expanded name notation to always be used
for the type in an object declaration, in order to resolve a name clash,
then File_Type would have been named just File.

As much as possible, I like to stick to the naming conventions in the
RM.  But this is my model.  For others, consistency with RM conventions
isn't a compelling enough argument.  Oh, well.

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Matt Heaney wrote (in comp.lang.ada):

:In an Ada declaration, the object and the type can't have the same name.
: ..  (Note that Eiffel doesn't have this "problem," because the object
:and its type are in different namespaces.)

to which I replied:

:> I think it's not so much namespaces but the fact that the syntax allows 
:> you (and the compiler) to easily differentiate variables (entities in 
:> Eiffel parlance) from types.
:> 
:> Some examples..
:> 
:> 1) Variable declarations:
:> 
:>        variable : TYPE
:> 
:>    The identifier to the left of the colon is recognised as a variable 
:>    and the one on the right as a type.
:
:But this is true in Ada too.  

The point is that Ada doesn't use that information to disambiguate, 
whereas Eiffel does.

Eiffel syntax is puposefully designed to leave no ambiguity as to what 
is a type and what is an entity - presumably so redundant information 
such as "_TYPE" can be omitted. It is the syntax, not different 
namespaces, that's responsible for the removal of ambiguity. The entity 
and its type happen to be defined in different modules, but that isn't 
why there is no ambiguity. If Eiffel syntax permitted it, they could be 
defined in the *same* namespace and there would still be no problem.


The question is: 

In Ada, is all syntax involving entities and types similarly unambiguous?
If so, the requirement, in Ada, that an entity and it's type have different 
names is an unnecessary one.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[Robert A Duff]

nospam@thanks.com.au (Don Harrison) writes:

> In Ada, is all syntax involving entities and types similarly unambiguous?
> If so, the requirement, in Ada, that an entity and it's type have different 
> names is an unnecessary one.

Almost, but not quite.  Eg, "Mumble'First" is a legal expression whether
Mumble is a type or an array object.  And "pragma Import(Eiffel, Mumble);"
is legal for practically any sort of Mumble.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Naming of Tagged Types and Associated Packages

[Don Harrison]

Bob Duff wrote:

:nospam@thanks.com.au (Don Harrison) writes:
:
:> In Ada, is all syntax involving entities and types similarly unambiguous?
:> If so, the requirement, in Ada, that an entity and it's type have different 
:> names is an unnecessary one.
:
:Almost, but not quite.  Eg, "Mumble'First" is a legal expression whether
:Mumble is a type or an array object.  And "pragma Import(Eiffel, Mumble);"
:is legal for practically any sort of Mumble.

Thanks for the clarification. Without checking, it appears there are few 
such ambiguities, so it might be possible to remove them in a future 
revision if considered worthwhile.


Don.
Don Harrison   donh at syd.csa.com.au

Re: Naming of Tagged Types and Associated Packages

[adam]

In article <wccemukwnx9.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> nospam@thanks.com.au (Don Harrison) writes:
>
> > In Ada, is all syntax involving entities and types similarly unambiguous?
> > If so, the requirement, in Ada, that an entity and it's type have different
> > names is an unnecessary one.
>
> Almost, but not quite.  Eg, "Mumble'First" is a legal expression whether
> Mumble is a type or an array object.  And "pragma Import(Eiffel, Mumble);"
> is legal for practically any sort of Mumble.

Also, Mumble(X) could be either an array element or a type conversion.

				-- Adam

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Static Polymorphism (Was Re: Naming of Tagged Types...)

[Brian Rogoff]

On Thu, 30 Jul 1998, Matthew Heaney wrote:
... snip ...
> Because I want a client to be able to easily change the code if he
> changes his mind about what kind of stack he needs (say, to go from a
> bounded stack to a dynamic stack with a statically allocated heap), I
> just named all the stack types Stack_Type.  (Brian Rogoff must be
> smiling right now...)   Just like File_Type.
> 
> This does not mean, however, that you should name every type using the
> _Type convention.  This is a big mistake, because then the convention
> would loose its value as an indicator of static polymorphism.
> 
> For example, the active iterator for the Stack_Type is called
> Stack_Iterator.  It's not just any Iterator_Type, it's an iterator for
> stacks, so call it that.

I wonder why you would want to name the iterator type Stack_Iterator,
since it seems to defeat the goals you describe for minimal rewriting
when changing implementation?
 
For example, if you wanted to replace the stack with a deque, or a singly 
linked list, you have to rename all occurrences of Stack_Iterator. If you 
take a look at the collection library at http://www.best.com/~bpr/agl.html 
which is also "tagged-type-free", you'll see that I copied from the C++
STL, and named the iterators based on the kinds of iteration they support,
Unidirectional, Bidirectional, Random_Access, etc., rather than on the
data structures they iterate over. This gives you what you are calling 
"static polymorphism", and allows you to write many algorithms in terms 
of iterators alone.

If you can tolerate reading C++, check out the STL, you'll find that you 
share some design goals with its authors.

-- Brian

PS: The sorting routines in my library right now weren't meant to work; I
just forgot to yank them out. I'll put real working versions on the net 
soon, after I figure out whether I want a Swap_Values routine in the
iterator signatures...

Re: Static Polymorphism (Was Re: Naming of Tagged Types...)

[Matthew Heaney]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I wonder why you would want to name the iterator type Stack_Iterator,
> since it seems to defeat the goals you describe for minimal rewriting
> when changing implementation?
>  
> For example, if you wanted to replace the stack with a deque, or a singly 
> linked list, you have to rename all occurrences of Stack_Iterator.

Yes, you would have to change the iterator, but you also have to change
all the stack instances, all the operation calls from Push to Add, the
selector from Get_Top to Get_Front, etc, etc, etc.

So I don't accept the premise of your argument.  The reason I chose a
stack in the first place is because I needed an ordered collection, that
has First-In Last-Out semantics.

If my requirements changed, and I needed a collection with different
semantics (say, I suddenly need First-In, First-Out) semantics, then
it's a Good Thing that I have to change all object declarations from
Stack_Type to Queue_Type.

If I didn't care about the collection being ordered, then certainly a
stack was _not_ the correct choice as my collection abstraction.  The
correct choice would be a Container_Type, which is an unordered
collection.

But to go from a stack to a list?  Why?  These are _really_ different
abstractions.  A stack is monolithic; a list polylithic.  The only time
I ever use a list is to implement a monolithic collection like a stack
or queue or container.  

Like an array, a list is a data structure that should only be used to
implement higher-level abstractions.  Never use a list (or array)
directly as a data structure.

> If you take a look at the collection library at
> http://www.best.com/~bpr/agl.html which is also "tagged-type-free",
> you'll see that I copied from the C++ STL, and named the iterators
> based on the kinds of iteration they support, Unidirectional,
> Bidirectional, Random_Access, etc., rather than on the data structures
> they iterate over. This gives you what you are calling "static
> polymorphism", and allows you to write many algorithms in terms of
> iterators alone.

I see your point of view; let me think about it for a while.  I only
implemented simple, one-way iterators (from front-to-back, or
top-to-bottom, etc). 

The implementation of the data structure can really limit what kinds of
iteration it supports.  For example, if you want to traverse a stack
from bottom to top, you really need to implement the stack using a
doubly-linked list, and, you have to have to a bottom pointer in
addition to the normal top pointer.

I'm not even sure some iteration schemes should be allowed.  For
example, does it make a lot of sense to have a random-access iterator
for a stack?  If so, then what's the point of using an ordered
collection?  And how do you implement a random-access iterator for a
stack implemented as a linked list?

Probably only one programmer in a thousand needs to randomly access a
stack.  In that case, he can just write a child to do that special thing
he needs.
 
> If you can tolerate reading C++, check out the STL, you'll find that you 
> share some design goals with its authors.

I'd really like to study the STL; I have the Stepanov book.  I'd bet I
could learn a lot of cool stuff.

But, as we have discussed in the past, the STL is a library highly
optimized for programming in C++.  Trying to apply STL ideas to Ada95
would be like trying to translate argot from French to English - how
well does it really translate?

In Ada95, a client can write a child package to extend the structure
with whatever custom operations the client requires.  Maybe that's the
better design choice, because it would keep the library simple, instead
of trying to anticipate all the myriad variations of iteration.

Re: Static Polymorphism (Was Re: Naming of Tagged Types...)

[Brian Rogoff]

On Thu, 6 Aug 1998, Matthew Heaney wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > I wonder why you would want to name the iterator type Stack_Iterator,
> > since it seems to defeat the goals you describe for minimal rewriting
> > when changing implementation?
> >  
> > For example, if you wanted to replace the stack with a deque, or a singly 
> > linked list, you have to rename all occurrences of Stack_Iterator.
> 
> Yes, you would have to change the iterator, but you also have to change
> all the stack instances, all the operation calls from Push to Add, the
> selector from Get_Top to Get_Front, etc, etc, etc.

Fortunately, Ada has renaming, subtypes, etc., etc.

> So I don't accept the premise of your argument.  The reason I chose a
> stack in the first place is because I needed an ordered collection, that
> has First-In Last-Out semantics.

Thats a stronger argument. An STL like solution is to provide some sort of 
adaptor on a collection to give the semantics you want. I guess when I'm 
using Push/Pop/Get_Top/etc I'm not thinking of using iterators anyways,
but I'm directly dealing with a stack and its elements.

... snip ...

> But to go from a stack to a list?  Why?  These are _really_ different
> abstractions.  A stack is monolithic; a list polylithic.  The only time
> I ever use a list is to implement a monolithic collection like a stack
> or queue or container.  
> 
> Like an array, a list is a data structure that should only be used to
> implement higher-level abstractions.  Never use a list (or array)
> directly as a data structure.

I guess I rarely use data structures directly now anyways :-), but in any
case I am pretty much in agreement with you here.

> > If you take a look at the collection library at
> > http://www.best.com/~bpr/agl.html which is also "tagged-type-free",
> > you'll see that I copied from the C++ STL, and named the iterators
> > based on the kinds of iteration they support, Unidirectional,
> > Bidirectional, Random_Access, etc., rather than on the data structures
> > they iterate over. This gives you what you are calling "static
> > polymorphism", and allows you to write many algorithms in terms of
> > iterators alone.
> 
> I see your point of view; let me think about it for a while.  I only
> implemented simple, one-way iterators (from front-to-back, or
> top-to-bottom, etc). 
> 
> The implementation of the data structure can really limit what kinds of
> iteration it supports.  For example, if you want to traverse a stack
> from bottom to top, you really need to implement the stack using a
> doubly-linked list, and, you have to have to a bottom pointer in
> addition to the normal top pointer.
> 
> I'm not even sure some iteration schemes should be allowed.  For
> example, does it make a lot of sense to have a random-access iterator
> for a stack?

No. I'd provide a stack adaptor (STL terminology) and apply that to a 
given collection to provide the desired stack semantics. I haven't
finished writing all of the stack/queue/etc. adaptors, since so far this 
AGL is a one man spare time show (remember, I'm really just a lowly 
C/Verilog/VHDL programmer) and I have limited time, but I think you can
see this isn't conceptually hard.

> If so, then what's the point of using an ordered
> collection?  And how do you implement a random-access iterator for a
> stack implemented as a linked list?

You don't.  

> > If you can tolerate reading C++, check out the STL, you'll find that you 
> > share some design goals with its authors.
> 
> I'd really like to study the STL; I have the Stepanov book.  I'd bet I
> could learn a lot of cool stuff.
> 
> But, as we have discussed in the past, the STL is a library highly
> optimized for programming in C++.  Trying to apply STL ideas to Ada95
> would be like trying to translate argot from French to English - how
> well does it really translate?

As we've dicussed before, you don't translate "word for word", even
between very similar languages, or you get oddities like 

"Can you him tomorrow pick up?" for "Kun je hem morgen afhalen?"

you have to have a sense of what translates and what doesn't. The main 
ideas of the STL translate quite well to Ada 95, some concepts don't need 
to be translated in the same way, and so on. Remember, the STL is based on 
earlier attempts in Scheme and Ada 83. Also, very similar libraries were 
proposed by Bishop (IEEE Transactions on SW Eng v16n4 1990 p389-402) in 
Ada 83, and I'm also stealing ideas from other sources (Stephen Leake,
take a bow), and adding new touches all the time as my knowledge of Ada 
95 deepens. But the proof of the pudding is in the source code, so if you
have some question about whether the library maps well to Ada, see the 
source.

-- Brian

PS: Its working on iteration libraries that made me something of a 
    downward-closure fanatic. Sure, I can do lots with generics, but 
    a genuine downward closure feature in Ada would make lots of code 
    less clunky.

Re: Naming of Tagged Types and Associated Packages

[Norman H. Cohen]

dennison@telepath.com wrote in message <6pirk1$iar$1@nnrp1.dejanews.com>...

>Again, you have encoded the fact that it is a type in the type's name. I
don't
>need that information, and it leads to really stupid looking things like
>"Command_Type_Type".


Consider Command_Variant_Type, or Command_Format_Type, or Command_Kind_Type.

The _Type suffix serves not only to announce "This is a type name," but to
leave other parts of the name space available for other purposes, e.g. for a
variable or formal parameter named Command_Kind, of type Command_Kind_Type.

-- Norman Cohen

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"Norman H. Cohen" <ncohen@us.ibm.com> writes:

> The _Type suffix serves not only to announce "This is a type name," but to
> leave other parts of the name space available for other purposes, e.g. for a
> variable or formal parameter named Command_Kind, of type Command_Kind_Type.

I usually just shorten the object name, so for me it would be Kind, of
type Command_Kind.

Re: Naming of Tagged Types and Associated Packages

[Stephen Leake]

"Norman H. Cohen" <ncohen@us.ibm.com> writes:

> dennison@telepath.com wrote in message <6pirk1$iar$1@nnrp1.dejanews.com>...
> 
> >Again, you have encoded the fact that it is a type in the type's name. I
> don't
> >need that information, and it leads to really stupid looking things like
> >"Command_Type_Type".
> 
> 
> Consider Command_Variant_Type, or Command_Format_Type, or Command_Kind_Type.
> 
> The _Type suffix serves not only to announce "This is a type name," but to
> leave other parts of the name space available for other purposes, e.g. for a
> variable or formal parameter named Command_Kind, of type Command_Kind_Type.

I'll go with Ted Dennison here, partly. I use _Type, and I often run
into hardware descriptions of the form "register x bits 1 .. 3 store
the command type", so the natural name for this object's type is
Command_Type_Type. I usually change the name to Command_Label_Type;
I'm more commited to _Type than to matching the hardware
documentation. That is bolstered by the fact that I have yet to find a
hardware manual with a clear, consistent naming convention, so I don't
mind "fixing" it.

-- Stephe

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dennison@telepath.com writes:

> Be careful. While this may be a nifty convention for ending discussions about
> the U.S. constitution, the Ada language designers aren't yet dead. In fact,
> they are still around and reading c.l.a. In my experience they have a rather
> annoying habit of piping in and disagreeing with me when I was sure they'd
> agree. :-)

Read the RM.  Show me one place in the RM where a type is named
"Instance."

If the language designers had intended for "type Instance is ..." to be
the convention, then surely Text_IO.File_Type would have been named that
way!

Re: Naming of Tagged Types and Associated Packages

[Jean-Pierre Rosen]

Matthew Heaney a �crit dans le message ...
>dennison@telepath.com writes:
>
>> Be careful. While this may be a nifty convention for ending discussions
about
>> the U.S. constitution, the Ada language designers aren't yet dead. In
fact,
>> they are still around and reading c.l.a. In my experience they have a
rather
>> annoying habit of piping in and disagreeing with me when I was sure
they'd
>> agree. :-)
>
>Read the RM.  Show me one place in the RM where a type is named
>"Instance."
The RM has many qualities, but it is certainly not intended to be used as an
example !
For example, it uses "with P; use P;" in every example, which lead people to
believe that the use clause had to be placed after the with, which lead in
turn people to forbid the use clause. Here, examples in the RM had the
effect of *defeating* the intended purpose of a language construct!

>If the language designers had intended for "type Instance is ..." to be
>the convention, then surely Text_IO.File_Type would have been named that
>way!

The purpose of this convention is restricted to OOP programming, and AFAIK
File_Type is not (visibly) tagged.
But the important thing is NOT that the name is "instance", "object", "T" or
"gizmo". The important thing is that there is a distinct identifier for the
main type of a package, and that the same identifier is used for all "class
packages", generic or not.
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:

> >Read the RM.  Show me one place in the RM where a type is named
> >"Instance."
> The RM has many qualities, but it is certainly not intended to be used as an
> example !

I take the opposite position, and try to follow the spirit of the
conventions in the RM.  Perhaps this is the real basis of our
disagreement.

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <m3d8aqxtau.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
>
> > >Read the RM.  Show me one place in the RM where a type is named
> > >"Instance."
> > The RM has many qualities, but it is certainly not intended to be used as an
> > example !
>
> I take the opposite position, and try to follow the spirit of the
> conventions in the RM.  Perhaps this is the real basis of our
> disagreement.

Does that mean back in the Ada83 days you made all your identifiers all upper-
case? Yuk.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dennison@telepath.com writes:

> > I take the opposite position, and try to follow the spirit of the >
> conventions in the RM.  Perhaps this is the real basis of our >
> disagreement.
> 
> Does that mean back in the Ada83 days you made all your identifiers
> all upper- case? Yuk.

No.  I used strict title format even in Ada 83.

Re: Naming of Tagged Types and Associated Packages

[Robert Dewar]

T.E.D. said

<<Does that mean back in the Ada83 days you made all your identifiers all upper-
case? Yuk.
>>

Many people preferred this concvention, and manhy still do.
It is a bit silly to say "Yuk" at someone else'es conventions, these
things are a matter of taste.

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> T.E.D. said
> 
> <<Does that mean back in the Ada83 days you made all your identifiers
> all upper- case? Yuk.
> >>
> 
> Many people preferred this concvention, and manhy still do.
> It is a bit silly to say "Yuk" at someone else'es conventions, these
> things are a matter of taste.

Fair enough, but in these days of Internet communication, if you write
SOMETHING in uppercase, reading it is like being screamed at.  

Also, humans read mixed-case text faster then all-caps.

Re: Naming of Tagged Types and Associated Packages

[Robert A Duff]

dennison@telepath.com writes:
> Be careful. While this may be a nifty convention for ending discussions about
> the U.S. constitution, the Ada language designers aren't yet dead. In fact,
> they are still around and reading c.l.a. In my experience they have a rather
> annoying habit of piping in and disagreeing with me when I was sure they'd
> agree. :-)

:-)

I'll just point out that this discussion about type names hinges on
whether you're a use-ophile or a use-ophobe.  To the former,
"X: Instance;" looks silly (or wrong); to the latter,
"X: Bounded_Text_Strings.Bounded_Text_String;" looks silly.

The strange thing about Ada is that the programmer who writes a package
must choose whether use_clauses will make sense (by choosing sensible
names for either option), whereas the client of that package gets to
choose whether to actually have a use_clause.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

Robert A Duff <bobduff@world.std.com> writes:

> I'll just point out that this discussion about type names hinges on
> whether you're a use-ophile or a use-ophobe.  To the former,
> "X: Instance;" looks silly (or wrong); to the latter,
> "X: Bounded_Text_Strings.Bounded_Text_String;" looks silly.
> 
> The strange thing about Ada is that the programmer who writes a package
> must choose whether use_clauses will make sense (by choosing sensible
> names for either option), whereas the client of that package gets to
> choose whether to actually have a use_clause.

Funny you should bring that up.  The more I think about it, the more I
think that use-semantics should be the default when you with a package.
In other words, the language should have been designed so that use
clauses weren't even necessary.

Your observation explains why some programmers object to the plural
package name convention, saying "Oh but that name just duplicates the
type name."  They must be use-a-phobics.

I'm a use-a-phile, so of course I'd use Bounded_Text_Strings, and
wouldn't dream of writing anything but

declare
   X : Bounded_Text_String;
begin

If you see a declaration like that, then there's a very high probability
that type Bounded_Text_String was declared in package
Bounded_Text_Strings, which is of course the reason for naming the
package that way.

Some shops give themselves rules like Thou Shalt Not Use Use, but that
rule is misguided.  The real rule should be, Thou Shall Make It Easy To
Trace A Type Back To The Package It's Declared In.  By naming the
package the plural of the type name, then the latter rule is satisfied,
in spite of use being used.

Re: Naming of Tagged Types and Associated Packages

[Tucker Taft]

We have been quite happy for the past 15 years (and > 1M SLOC)
using the with/rename approach, exemplified by:

with Ada.Strings.Bounded;
  ...
    package ASB renames Ada.Strings.Bounded;
  ...

    X : ASB.Bounded_String;

  ...

    if ASB.Length(X) = 0 then ...

This makes it very easy to follow all references, without 
overwhelming the user with repetitive, long-winded package
names everywhere.  All of the package renames are at the
beginning of the compilation unit containing the references.
Ideally, the abbreviations are agreed-upon on a project-wide basis.

For primitive operators (presuming they have their "intuitive" meaning ;-), 
I would certainly recommend "use type", but given the above approach, 
there is almost never a need for "use"ing a package.
    
--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar company.

Re: Naming of Tagged Types and Associated Packages

[Matthew Heaney]

stt@houdini.camb.inmet.com (Tucker Taft) writes:

> We have been quite happy for the past 15 years (and > 1M SLOC)
> using the with/rename approach, exemplified by:
> 
> with Ada.Strings.Bounded;
>   ...
>     package ASB renames Ada.Strings.Bounded;
>   ...
> 
>     X : ASB.Bounded_String;
> 
>   ...
> 
>     if ASB.Length(X) = 0 then ...

I find this style a bit old-fashioned.  

First of all, you don't need to tell me every time you invoke an
operation on X that the operation is defined in package ASB.  I already
know that, because you said so in the declaration.  So why tell me
again, and again, and again...?

Of course, you might be using a non-primitive operation defined in some
package other than ASB.  If the operation is defined in a non-obvious
place, then perhaps it does make sense to use an expanded name.

But, if the defining packages are carefully named, then that gives you a
strong clue that that's where an operation or type is coming from.  For
example, if I see the declaration

   X : Bounded_String;
...

then I'm going to look at the context clause for a package named
Bounded_Strings.  The ASB part (or even a fully expanded name) is
largely redundant.

If the operation is non-primitive (meaning I didn't find it in the
package that declared the type), then I'd look for some other clue about
its origin.  For example, if I saw this

   Some_Weird_Operation (X);

then I'd look for a package called Bounded_String_Utilities, or
something like that.

Of course, if the (non-primitive) operation is not declared in an
obvious place, then it is wise for the writer to give the reader a hint
as to it's origin, perhaps using the expanded name notation technique
you mention.

Remember, types and operations usually go together.  Tell me where one
is, and that's usually where I'll find the other too.

> This makes it very easy to follow all references, without 
> overwhelming the user with repetitive, long-winded package
> names everywhere.  All of the package renames are at the
> beginning of the compilation unit containing the references.
> Ideally, the abbreviations are agreed-upon on a project-wide basis.

My personal experience is that abbreviations of this kind are usually
unreadable.  If a shop is really allergic to use clauses in the context
clause, then I prefer this sort of thing:

with Ada.Strings.Bounded_Strings;
...

   X : Ada.Strings.Bounded_Strings.Bounded_String;

   use Ada.Strings.Bounded_Strings;
begin
   if Length (X) = 0 then ...;

The idea is to use fully qualified types in the object declaration,
followed by a use clause just prior to the end of the declarative
region.

A compromise position is:

with Ada.Strings.Bounded_Strings;  use Ada.Strings;

That way I only have to specify the most deeply-nested package in a
declaration:

   X : Bounded_Strings.Bounded_String;

   use Bounded_Strings;
begin


But you see even from the example above that expanded name
Bounded_Strings.Bounded_String is a bit redundant.  If I have a type
named Bounded_String in a scope, from what package other then
Bounded_Strings can it come from?

Re: Naming of Tagged Types and Associated Packages

[tmoran]

>The addition of tagged types in Ada 95 is good, but it doesn't change
>implementation techniques that much from Ada 83, because you should
>already be using type-based abstractions where that makes sense.
  There are some things Ada 95 lets you do that were *extremely*
inconvenient, in Ada 83.  Controlled types, which let a task execute
code after an "or terminate" select alternative, and "access T'Class"
which lets you link heterogenous data simply, come to mind.  For a
slightly more complex example, a system I'm working on has a
library-level task and task safety (and the OS, in this case) requires
that certain things only be done by that task.  Occasionaly, we've
needed to add a new operation.  At first we added a new 'entry' and
recompiled the world.  Then we realized that there can be one entry
that takes a classwide parameter and calls a standard "Do_Whatever"
procedure, passing that parameter.  Now a new operation merely
requires a new descendant of the (abstract) root type with appropriate
information in the new extension part, and an overriding "Do_Whatever"
that will be run from the correct task.  No spec changes to the task
and thus no recompilation.  Tagged types are a new tool.  There's no
requirement to limit their use to what the designers, or OO
philosophy, intended.

Re: Naming of Tagged Types and Associated Packages

[dennison]

In article <6pfs36$8rh@lotho.delphi.com>,
  tmoran@bix.com wrote:
> >The addition of tagged types in Ada 95 is good, but it doesn't change
> >implementation techniques that much from Ada 83, because you should
> >already be using type-based abstractions where that makes sense.
>   There are some things Ada 95 lets you do that were *extremely*
> inconvenient, in Ada 83.  Controlled types, which let a task execute

I had need of dynamic dispatching in Ada 83 once. I had to write a big honking
case statement that looked like this:

  case Command.First_Byte is  when Command_1 => 
Command_1_Pkg.Do_It(Unchecked_Convert_To_Command_1_Type(Command));  .  .  . 
when Command_120 => 
Command_120_Pkg.Do_It(Unchecked_Convert_To_Command_120_Type(Command));	end
case;

I spent *weeks* writing that thing. But a tagged type would have made this 20
page routine a 1-liner!

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum