on package naming, should the word "_pkg" be part of it?

on package naming, should the word "_pkg" be part of it?

[mike]

i've seen some code where they write

package foo_pkg is...


i.e. the name of the package contains "pkg" or "package" in the name itself.

this seems redundent to me, but may be not. what do folks think? 

mike

Re: on package naming, should the word "_pkg" be part of it?

[Larry Hazel]

"mike@nospam" wrote:
> 
> i've seen some code where they write
> 
> package foo_pkg is...
> 
> i.e. the name of the package contains "pkg" or "package" in the name itself.
> 
> this seems redundent to me, but may be not. what do folks think?
> 
> mike

That is sponsored by the Department of Redundancy Department.  I think it is an
ugly distraction, similar to adding _Type to type names.  I notice the RM
doesn't defint Integer_Type, Float_Type, etc.

Larry

Re: on package naming, should the word "_pkg" be part of it?

[Pascal Obry]

Larry Hazel <lhhazel@otelco.net> writes:

> 
> That is sponsored by the Department of Redundancy Department.  I think it is an
> ugly distraction, similar to adding _Type to type names.  I notice the RM
> doesn't defint Integer_Type, Float_Type, etc.

No but it does define File_Type :) But I find also ugly the _pck. Better to
find the right name for the package.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: on package naming, should the word

[Ted Dennison]

In article <3BBCC7EF.6C59C85D@otelco.net>, Larry Hazel says...
>"mike@nospam" wrote:
>> package foo_pkg is...
>> 
>> i.e. the name of the package contains "pkg" or "package" in the name itself.
>> 
>> this seems redundent to me, but may be not. what do folks think?
>That is sponsored by the Department of Redundancy Department.  I think it is an
>ugly distraction, similar to adding _Type to type names.  I notice the RM
>doesn't defint Integer_Type, Float_Type, etc.

I think its dangerous to point to the LRM as the cannonical source of proper
naming, but otherwise I agree completely.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Preben Randhol]

On Thu, 04 Oct 2001 21:04:49 GMT, Ted Dennison wrote:
> In article <3BBCC7EF.6C59C85D@otelco.net>, Larry Hazel says...
>>"mike@nospam" wrote:
>>> package foo_pkg is...
>>> 
>>> i.e. the name of the package contains "pkg" or "package" in the name itself.
>>> 
>>> this seems redundent to me, but may be not. what do folks think?
>>That is sponsored by the Department of Redundancy Department.  I think it is an
>>ugly distraction, similar to adding _Type to type names.  I notice the RM
>>doesn't defint Integer_Type, Float_Type, etc.
> 
> I think its dangerous to point to the LRM as the cannonical source of proper
> naming, but otherwise I agree completely.

:-( I thought it made the source code even more readable. Especially to
add _Type to ones own types. It also removes namespace
mixups/limitations. I mean if you define a type and you call it say:
Word_Type you can still use Word as the variable name.

I can see that skipping _Pkg may be better though...

Preben Randhol

Re: on package naming, should the word

[Brian Rogoff]

On Thu, 4 Oct 2001, Preben Randhol wrote:
> On Thu, 04 Oct 2001 21:04:49 GMT, Ted Dennison wrote:
> > In article <3BBCC7EF.6C59C85D@otelco.net>, Larry Hazel says...
> >>"mike@nospam" wrote:
> >>> package foo_pkg is...
> >>>
> >>> i.e. the name of the package contains "pkg" or "package" in the name itself.
> >>>
> >>> this seems redundent to me, but may be not. what do folks think?

About redundancy? Go to http://www.averstar.com/~stt/tools99lang.htm and
click on the section titled "The Big Trick to Catching Errors Early".

> >>That is sponsored by the Department of Redundancy Department.  I think it is an
> >>ugly distraction, similar to adding _Type to type names.  I notice the RM
> >>doesn't defint Integer_Type, Float_Type, etc.
> >
> > I think its dangerous to point to the LRM as the cannonical source of proper
> > naming, but otherwise I agree completely.
>
> :-( I thought it made the source code even more readable. Especially to
> add _Type to ones own types.

Lots of people like that style in Ada. I do. Norman Cohen uses it
consistently in his textbook, even though one could make a good argument
for using a terser style in a textbook. John English uses it in his
textbook. If types had a separate namespace then that might tip the
balance for me, but they don't, so I prefer this bit of redundancy.

For packages, I don't like it so much either, but I like to use
descriptive package names, very short type names (like "T" when there is
just one public type in the package) and fully qualified names (though I
despise rules like "never use use" and dislike the "use type" construct of
Ada 95). De gustibus...

-- Brian

Re: on package naming, should the word

[Larry Kilgallen]

In article <20011004150358.M14557-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:

> About redundancy? Go to http://www.averstar.com/~stt/tools99lang.htm and
> click on the section titled "The Big Trick to Catching Errors Early".

That is not visible without JavaScript.

Re: on package naming, should the word

[Preben Randhol]

On 4 Oct 2001 18:38:08 -0500, Larry Kilgallen wrote:
> In article <20011004150358.M14557-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
>> About redundancy? Go to http://www.averstar.com/~stt/tools99lang.htm and
>> click on the section titled "The Big Trick to Catching Errors Early".
> 
> That is not visible without JavaScript.

It says:

The Big Trick to Catching Errors Early

. Redundancy
   - Force the programmer to follow the writing-teacher's
   rule:
      . Tell you what they are going to say
      . Tell you
      . Tell you what they said
   - Kinds of Redundancy:
      . Type Declarations
      . Subrange Declarations
      . var vs. const, in vs. out specification
      . Assertions, Pre/Post Conditions
      . Separation of Interface and Implementation
   - Tools should check for consistency

Preben Randhol

Re: on package naming, should the word

[MM]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]


In article <slrn9rq4b0.1vp.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
says...
>
>On 4 Oct 2001 18:38:08 -0500, Larry Kilgallen wrote:
>>In article <20011004150358.M14557-100000@shell5.ba.best.com>, Brian Rogoff
>><bpr@shell5.ba.best.com> writes:
>> 
>>> About redundancy? Go to http://www.averstar.com/~stt/tools99lang.htm and
>>> click on the section titled "The Big Trick to Catching Errors Early".
>> 
>> That is not visible without JavaScript.
>

From the above link:


"And the winner is...
              
� For Separated Interface and Implementation
  
� Ada and Modula seem the clear winners given universal use of spec/body
separation
  
 
� For Pre/Post conditions:
  
 � Eiffel is most flexible game in town
 � Ada subranges provide some pre/post condition indications

  
� For Parameter/Result type specification
 
 � Ada provides most checking against Sins of Confusion"



gee, Ada beat Java and C and C++, but we all knew that :)



 
 
 

Re: on package naming, should the word

[Brian Rogoff]

On 4 Oct 2001 MM@MM wrote:
> In article <slrn9rq4b0.1vp.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
> says...
> >
> >On 4 Oct 2001 18:38:08 -0500, Larry Kilgallen wrote:
> >>In article <20011004150358.M14557-100000@shell5.ba.best.com>, Brian Rogoff
> >><bpr@shell5.ba.best.com> writes:
> >>
> >>> About redundancy? Go to http://www.averstar.com/~stt/tools99lang.htm and
> >>> click on the section titled "The Big Trick to Catching Errors Early".
>
> "And the winner is...
[...snip...]
> gee, Ada beat Java and C and C++, but we all knew that :)

Actually, Tucker pointed out some places where Eiffel, Java and even C++
did well better than Ada. I really dislike Eiffel, and class obsessed
languages (sounds commmunist to me! ;-) but I have to admit that it has a
more elaborate assertion mechanism than Ada.

Anyways, to digress a bit, if you're interested in some "academic fiddling"
which may have some impact on the safety issues you should look up
dependent types. Hongwei Xi has done some interesting work; start here

http://www.ececs.uc.edu/~hwxi/
http://www.ececs.uc.edu/~hwxi/Xanadu/Xanadu.html

Another intriguing avenue of research is proof carrying code.

The bummer to me is that noone makes an Ada like language which
incorporates these new concepts. Oh well, I like ML too I guess it isn't
all bad :-)

-- Brian

Re: on package naming, should the word

[tmoran]

>I think its dangerous to point to the LRM as the cannonical source of proper
>naming, ...
  Pointing to "Ada 95 Quality and Style", online at
http://www.grammatech.com/style_guide/cover.html
might be a better idea.

Re: on package naming, should the word

[Ted Dennison]

In article <R65v7.4436$IY3.2733531@news1.rdc1.sfba.home.com>, tmoran@acm.org
says...
>
>>I think its dangerous to point to the LRM as the cannonical source of proper
>>naming, ...
>  Pointing to "Ada 95 Quality and Style", online at
>http://www.grammatech.com/style_guide/cover.html
>might be a better idea.

In which case, the appropriate link would be
http://www.grammatech.com/style_guide/sec_3a.html#3.2.4 , although it talks
about the naming of packages *and* their associated tagged types. If you are
making a package without tagged types, there really isn't any help in there for
you. (But _pkg is *still* out!)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word "_pkg" be part of it?

[Marin David Condic]

You'll get a variety of opinions on this. Its a naming convention that
various projects might adopt and it might have some food value to it.
Consider that if you run into an identifier that has some sort of indication
of what it identifies in the name, it make it obvious what you're looking
at.

OTOH, many will say that it unnecessarily clutters up the code and makes
names of things stilted & less meaningful. There is something to that case
as well - especially when a development environment gives you the capability
of highlighting an identifier and requesting its definition, etc.

My general opinion is that if a project adopts a naming convention, everyone
should strive to preserve it for the sake of consistency - no matter how
stupid a convention it may be. For small projects or reusable components I'd
prefer that names simply be meaningful. For larger projects that may be
around for a while, I have found some advantages to having a naming
convention for objects and types, but not generally for library units. I do
like dividing a project up into subsystems and having each subsystem have a
short-named root package since then the dotted notation and file names
naturally identify what subsystem a thing belongs to.

You might as well ask what conventions people prefer for character case on
reserved words & identifiers. You'll get a zillion varying opinions on that
too! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"mike@nospam" <mike_member@newsguy.com> wrote in message
news:9pif1o01btl@drn.newsguy.com...
> i've seen some code where they write
>
> package foo_pkg is...
>
>
> i.e. the name of the package contains "pkg" or "package" in the name
itself.
>
> this seems redundent to me, but may be not. what do folks think?
>
> mike
>

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Thu, 4 Oct 2001 16:53:56 -0400, "Marin David Condic"
<dont.bother.mcondic.auntie.spam@[acm.org> wrote:

>My general opinion is that if a project adopts a naming convention, everyone
>should strive to preserve it for the sake of consistency - no matter how
>stupid a convention it may be.

I agree, but it is obviously worth coming to some agreement on a
convention that is not stupid in the first place.

There is an article available somewhere on the net about Lessons
Learned using Ada 95 in an OO Environment. It suggests things like, if
you're using a package with a single tagged type as a kind of class,
then name the package after its purpose and name the tagged type
Object! So you get something like:

package Car is

    type Object is tagged
        record
            ....
        end record;

    procedure DoSomething (This : in Object);
    ....
end Car;

In my last Ada position we found a large number of cases where this
was just not sensible. Finally our agreement was to use the package
name as the plural of the type of information it contained. So we
would have:

package Cars is

    type Car is tagged
        record
            ....
        end record;

    procedure DoSomething (This : in Car);
    ....
end Cars;

This generally worked pretty well, but we sometimes had some silly
names for packages because of strange pluralisations on words like
Radius etc!

As far as _Type is concerned - I'm all for it, but it can be avoided
by using The_ in front of objects. For example:

   type Car_Type is
       record
          ....
       end record;

   procedure DoSomething (Car : in out Car_Type);

could be replaced by:

   type Car is
       record
          ....
       end record;

   procedure DoSomething (The_Car : in out Car);

At the end of the day, as long as everyone is reasonably happy with
whatever convention is decided on, *and follows it*, then there
shouldn't be a problem.

John

Re: on package naming, should the word "_pkg" be part of it?

[mike]

In article <3bbd7a77.5463085@news.demon.co.uk>, john.mccabe@emrad.com.nospam
says...
>
 

>In my last Ada position we found a large number of cases where this
>was just not sensible. Finally our agreement was to use the package
>name as the plural of the type of information it contained. So we
>would have:
>
>package Cars is
>
>    type Car is tagged
>        record
>            ....
>        end record;
>
>    procedure DoSomething (This : in Car);
>    ....
>end Cars;
>
 

These sorts of things are never a problem in Java.  Do not see why Ada
programmers always have a problem with it.

For example, in Java, the package java.awt.event contains these classes:

ActionEvent
AdjusmentEvent
ComponentAdapter
ContainerAdapter
etc...

The reason to having these problems with Ada is this: In Java, each class 
goes into one separate file (in general, public classes, etc..), and in
Java, a package is not a physical thing, it is the name of the directory
where the classes sit. i.e. there is no physical file that represents
a package.

In Ada, many do not like a use single package file to contain 20 tagged
records declarations in the same file with all the primitive operations
on each one of those tagged record, and they want to have a one 
tagged record per one package. This causes the above naming problem.

So, I do not see why one can't do this in Ada

package Ada.awt.event is
  type ActionEvent is tagged record .... end record;
     -- primitive operations on ActionEvent here

  type AdjustmentEvent is tagged record .... end record;
     -- primitive operations on AdjutsmentEvent here

  type ActionEvent is tagged record .... end record;
     -- primitive operations on ActionEvent here

  type ComponentAdapter is tagged record .... end record;
     -- primitive operations on ComponentAdapter here
  
   etc...
end Ada.awt.event;


Using the above, will solve all these naming problem. But what it will
do, is make the java package file HUGE. It is basically like putting
all the code in those separate java class files into one big file.

This means if one modifies one line of code the package file,
many other files will have to be recompiled. No big deal, computers
are fast these days. 

After all, a package should contain related types in it, and if the package
happened to have 20-30 related types, so they all go into the same one
physical file (i.e. same package).

Re: on package naming, should the word "_pkg" be part of it?

[Stephen Leake]

mike@nospam <mike_member@newsguy.com> writes:

> These sorts of things are never a problem in Java.  Do not see why Ada
> programmers always have a problem with it.
> 
> For example, in Java, the package java.awt.event contains these classes:
> 
> ActionEvent
> AdjusmentEvent
> ComponentAdapter
> ContainerAdapter
> etc...

So you are saying the convention in Java is to allways include some
type information in the name. 

How do you name something that is a list of arrays of pointers to
symbol table entries?

> The reason to having these problems with Ada is this: In Java, each
> class goes into one separate file (in general, public classes,
> etc..), and in Java, a package is not a physical thing, it is the
> name of the directory where the classes sit. i.e. there is no
> physical file that represents a package.

So what name do you give to the directory? Does it end in Package?

> In Ada, many do not like a use single package file to contain 20
> tagged records declarations in the same file with all the primitive
> operations on each one of those tagged record, and they want to have
> a one tagged record per one package. This causes the above naming
> problem.

Huh? Ahh. In Java, you put many classes in one directory. Ok. In Ada,
you can have many child packages of one parent package; same naming
conventions.

> So, I do not see why one can't do this in Ada
> 
> package Ada.awt.event is
>   type ActionEvent is tagged record .... end record;
>      -- primitive operations on ActionEvent here
> 
>   type AdjustmentEvent is tagged record .... end record;
>      -- primitive operations on AdjutsmentEvent here
> 
>   type ActionEvent is tagged record .... end record;
>      -- primitive operations on ActionEvent here
> 
>   type ComponentAdapter is tagged record .... end record;
>      -- primitive operations on ComponentAdapter here
>   
>    etc...
> end Ada.awt.event;

Perfectly legal Ada, except that the root is 'Standard', not 'Ada'. An
alternative is:

package Awt.Event is
end package;

package Awt.Event.Actions is
    type Action is tagged record ... end record;
end Awt.Event.Actions;

etc.

In Ada, you get a choice. In Java, you don't. So in that sense, Ada is
harder to use, because you have to make the choice!

> Using the above, will solve all these naming problem. But what it
> will do, is make the java package file HUGE. It is basically like
> putting all the code in those separate java class files into one big
> file.

Which is why Ada 95 has child packages.

> This means if one modifies one line of code the package file, many
> other files will have to be recompiled. No big deal, computers are
> fast these days.

Well, it is a big deal for other reasons as well; consider change
tracking. 

> After all, a package should contain related types in it, and if the
> package happened to have 20-30 related types, so they all go into
> the same one physical file (i.e. same package).

Better to put them in a package tree.

-- 
-- Stephe

Re: on package naming, should the word "_pkg" be part of it?

[mike]

In article <ueloiw6ys.fsf@gsfc.nasa.gov>, Stephen says...
>
> 
>> 
>> For example, in Java, the package java.awt.event contains these classes:
>> 
>> ActionEvent
>> AdjusmentEvent
>> ComponentAdapter
>> ContainerAdapter
>> etc...
>

>So you are saying the convention in Java is to allways include some
>type information in the name. 
>

no. not at all.

>How do you name something that is a list of arrays of pointers to
>symbol table entries?
>
 
there are no pointers in java :)

You can use an ArrayList class for the above:

ArrayList m= new ArrayList( ....) ;  // many different constructors exist.

>So what name do you give to the directory? Does it end in Package?
>

the directory name is the package name. no it does not end in a "package".
for example, java.lang is located in the "folder" java/lang/ 

 
>
>Huh? Ahh. In Java, you put many classes in one directory. 

Yes, those classes that belong to that package.

>Ok. In Ada,
>you can have many child packages of one parent package; same naming
>conventions.
>

Yes, but each one of those files in Ada is a package itself (a child package,
but a package none-the-less). In Java, it is silly to have a package that
contains only ONE class. (i.e. a directory that contains one file). usually
a package contains few classes at least, and it is not uncommon to have 10-20
classes (files) in one directory (package) in Java. 




 

Re: on package naming, should the word

[Ted Dennison]

In article <9pk2dq01gvu@drn.newsguy.com>, mike@nospam says...
>
>These sorts of things are never a problem in Java.  Do not see why Ada
>programmers always have a problem with it.

The issue in Ada is that the OO concept of a "class" is not implemented by a
single syntax element, like it is in Java or most other OO languages. Instead it
is implemented by a package and a tagged type *together*.

That means that in effect *both* the tagged type and the package are the class,
and thus logicly (in most folks heads) deserve the same name. The only good way
out of this quandry is to come up with an arbitrary convention. Since its
arbitrary, no one convention is clearly superior to the other, so there are
several equally valid styles floating around.

>For example, in Java, the package java.awt.event contains these classes:
>
>ActionEvent
>AdjusmentEvent
>etc...

I know there are other issues with the package in Java. But if this were Ada,
I'd say you'd need to take "event" off of the first two.
Java.AWT.Event.ActionEvent contains redundant naming information.

>So, I do not see why one can't do this in Ada
>
>package Ada.awt.event is
>  type ActionEvent is tagged record .... end record;
>     -- primitive operations on ActionEvent here
>
>  type AdjustmentEvent is tagged record .... end record;
>     -- primitive operations on AdjutsmentEvent here
>
>  type ActionEvent is tagged record .... end record;
>     -- primitive operations on ActionEvent here
>
>  type ComponentAdapter is tagged record .... end record;
>     -- primitive operations on ComponentAdapter here
>  
>   etc...
>end Ada.awt.event;

You don't want to do this, because it gives all these classes complete
visibility into each other's implementation. Also, any use of one within the
other may cause premature freezing problems in the spec.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[mike]

In article <jCjv7.17235$ev2.27212@www.newsranger.com>, Ted says...
>
 

>>So, I do not see why one can't do this in Ada
>>
>>package Ada.awt.event is
>>  type ActionEvent is tagged record .... end record;
>>     -- primitive operations on ActionEvent here
>>
>>  type AdjustmentEvent is tagged record .... end record;
>>     -- primitive operations on AdjutsmentEvent here
>>
>>  type ActionEvent is tagged record .... end record;
>>     -- primitive operations on ActionEvent here
>>
>>  type ComponentAdapter is tagged record .... end record;
>>     -- primitive operations on ComponentAdapter here
>>  
>>   etc...
>>end Ada.awt.event;

>
>You don't want to do this, because it gives all these classes complete
>visibility into each other's implementation. 

I was mapping the Java classes/packge to Ada. In Java, all classes in 
the same package have the default access such that they can see each others.
 
(you have the supply the keyword protected on private on the methods and
data member to restrict this). 

so, in java, when you say

class foo; ---> in file foo.java
class moo; --->  in fle moo.java

and both those class are in the same directory (i.e. package), then each
method in each class can see all other methods and data in the other
class (unless you make such method or data members protected or private)...







 

Re: on package naming, should the word

[Ted Dennison]

In article <9pkicf02ncr@drn.newsguy.com>, mike@nospam says...
>
>In article <jCjv7.17235$ev2.27212@www.newsranger.com>, Ted says...
>>
>>>So, I do not see why one can't do this in Ada
>>>
>>>package Ada.awt.event is
>>>  type ActionEvent is tagged record .... end record;
>>>     -- primitive operations on ActionEvent here
>>>
>>>  type AdjustmentEvent is tagged record .... end record;
>>>     -- primitive operations on AdjutsmentEvent here
>>>   etc...
>>>end Ada.awt.event;
>
>>
>>You don't want to do this, because it gives all these classes complete
>>visibility into each other's implementation. 
>
>I was mapping the Java classes/packge to Ada. In Java, all classes in 
>the same package have the default access such that they can see each others.


The proper progression for classes A and B in Ada is:

1) If A and B can't see each other's "protected" areas, then they should be in
different packages.

2) If A *can* see B's "protected" area, but not visa-versa, then A should be in
a child package of B.

3) If they are so horribly intertwined that they need to see each other's
"protected" areas, then they must go in the same package (assuming you can't
find some way to untangle them a bit). However, this is quite a bit stronger
than 2, as A and B can also share invisible implementation data that isn't
available to children (because its declared in the body of the package). As a
reader client of them, I have to assume that this kind of interaction can be
going on, and thus there really is no clearly-defined separation between A and
B. They are like "Siameese twins", possibly sharing vital organs.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Francisco Javier Loma Daza]

Ted Dennison wrote:

> In article <9pkicf02ncr@drn.newsguy.com>, mike@nospam says...
> >
> >In article <jCjv7.17235$ev2.27212@www.newsranger.com>, Ted says...
> >>
> >>>So, I do not see why one can't do this in Ada
> >>>
> >>>package Ada.awt.event is
> >>>  type ActionEvent is tagged record .... end record;
> >>>     -- primitive operations on ActionEvent here
> >>>
> >>>  type AdjustmentEvent is tagged record .... end record;
> >>>     -- primitive operations on AdjutsmentEvent here
> >>>   etc...
> >>>end Ada.awt.event;
> >
> >>
> >>You don't want to do this, because it gives all these classes complete
> >>visibility into each other's implementation.
> >
> >I was mapping the Java classes/packge to Ada. In Java, all classes in
> >the same package have the default access such that they can see each others.
>
> The proper progression for classes A and B in Ada is:
>
> 1) If A and B can't see each other's "protected" areas, then they should be in
> different packages.
>

    Well... they can be in different packages if they DO NOT depend on each other.
Say

-- file A.ads
with B;
package A is

    type Object is private;

    procedure Send(this: Object; to: B.Object);
end A;

--file B.ads
with A;
package B is

    type Object is private;

    procedure Send(this: Object; to: A.Object);

end B;


Will be 'with type' really standarized?, I hope so

Re: on package naming, should the word

[Simon Wright]

Francisco Javier Loma Daza <Francisco.Loma@isotrol.com> writes:

> Will be 'with type' really standarized?, I hope so

I certainly hope so! (well, it looks as though it won't be WITH TYPE
but something allowing you to meet the requirement).

Re: on package naming, should the word

[Marc A. Criley]

Francisco Javier Loma Daza wrote:
> 
  <snip>
> 
>     Well... they can be in different packages if they DO NOT depend on each other.
> Say
> 
> -- file A.ads
> with B;
> package A is
> 
>     type Object is private;
> 
>     procedure Send(this: Object; to: B.Object);
> end A;
> 
> --file B.ads
> with A;
> package B is
> 
>     type Object is private;
> 
>     procedure Send(this: Object; to: A.Object);
> 
> end B;
> 
> Will be 'with type' really standarized?, I hope so

Mutual dependence will almost certainly be in Ada 200Y in some form. 
The Ada Rapporteurs (sp?) are working out the exact approach and
details.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

"mike@nospam" wrote:
> 
> The reason to having these problems with Ada is this: In Java, each class
> goes into one separate file (in general, public classes, etc..), and in
> Java, a package is not a physical thing, it is the name of the directory
> where the classes sit. i.e. there is no physical file that represents
> a package.

The term "package" has completely different meanings in Ada and Java, so
I find this entire discussion irrelevant.

-- 
Jeffrey Carter

Re: on package naming, should the word "_pkg" be part of it?

[Marin David Condic]

Oh sure. Of course. If the project is of any appreciable size, the team
should sit down before doing design and agree on some convention. If the
organization has had prior projects, then there may be conventions already
in place that are suitable or maybe suitable with modifications based on
experience. Try to have something that makes sense and has some general
agreement and isn't too restrictive. Then stick with it. Its always a lot
easier to come onto a project at a later point and read code all over the
place that is reasonably consistent in style. You pick up the flavor of the
project and can then more easily understand what everyone was doing. The
real enemy is confusion. If the project uses _Type, keep uising _Type
because otherwise someone is going to see Some_Identifier and presume it
isn't a type.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"John McCabe" <john.mccabe@emrad.com.nospam> wrote in message
news:3bbd7a77.5463085@news.demon.co.uk...
>
> I agree, but it is obviously worth coming to some agreement on a
> convention that is not stupid in the first place.
>

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

John McCabe wrote:
> 
>    type Car_Type is
>        record
>           ....
>        end record;
> 
>    procedure DoSomething (Car : in out Car_Type);
> 
> could be replaced by:
> 
>    type Car is
>        record
>           ....
>        end record;
> 
>    procedure DoSomething (The_Car : in out Car);

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

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

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

type Car_Info ...

procedure P (Car : in Car_Info ...

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

-- 
Jeffrey Carter

Re: on package naming, should the word "_pkg" be part of it?

[Wes Groleau]

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

And there's a real shortage of thought
in our industry, so we must use it
very sparingly.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: on package naming, should the word "_pkg" be part of it?

[Vincent Marciante]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3BBDE9BA.CF042BC9@boeing.com...
> John McCabe wrote:
> >
> >    type Car_Type is
> >        record
> >           ....
> >        end record;
> >
> >    procedure DoSomething (Car : in out Car_Type);
> >
> > could be replaced by:
> >
> >    type Car is
> >        record
> >           ....
> >        end record;
> >
> >    procedure DoSomething (The_Car : in out Car);
>
> I recall reading articles about the psychology of understanding programs
> (sorry, Robert Dewar, I don't have references for this, either.
> Hopefully it's not just random neurons firing in my brain) that stated
> that the first few characters of an identifier are the most important in
> determining what you're reading. Having identifiers that are identical
> for the first few characters requires more time and effort to
> understand, and results in more errors in understanding.
>
> Although both _Type and The_ are ways to resolve the type/parameter name
> conflict, The_ is worse because it makes the first four characters of
> every parameter name the same.
>
> I make the type name reflect what the type contains. For example
>
> type Car_Info ...
>
> procedure P (Car : in Car_Info ...
>
> This is not a popular approach, though, because it requires thought
> about every type name.
>
> --
> Jeffrey Carter


What about the following:

package XYZ is

     type Car ...

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


--
Vinny

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Fri, 5 Oct 2001 15:17:35 -0400, "Vincent Marciante" >>

>What about the following:
>
>package XYZ is
>
>     type Car ...
>
>     procedure P (Car : in XYZ.Car ...

Oh yes - very nice ;-}

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

"mike@nospam" wrote:
> 
> i've seen some code where they write
> 
> package foo_pkg is...
> 
> i.e. the name of the package contains "pkg" or "package" in the name itself.
> 
> this seems redundent to me, but may be not. what do folks think?

Yes, it is redundant. But remember, these are all good things:

package Foo_Package is ...
type Radian_Type is ...
procedure Calculate_Procedure (Initial_Guess_In_Float_Parameter : in
Float ...
Number_Of_Widgets_Positive_Variable : Positive;
Pi_Real_Constant : Constant := 3.14159;
Maximum_Word_Length_Positive_Constant : constant Positive := X'Last +
Padding;

except of course X and Padding are terrible names with no redundant
information.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail

Re: on package naming, should the word "_pkg" be part of it?

[Simon Wright]

Jeffrey Carter <jrcarter@acm.org> writes:

> package Foo_Package is ...
> type Radian_Type is ...
> procedure Calculate_Procedure (Initial_Guess_In_Float_Parameter : in
> Float ...
> Number_Of_Widgets_Positive_Variable : Positive;
> Pi_Real_Constant : Constant := 3.14159;
> Maximum_Word_Length_Positive_Constant : constant Positive := X'Last +
> Padding;

Are you pulling our collective leg here?

Just to take that procedure .. what happens if it turns into a Double,
for instance?

I'm all in favour of thinking of sensible and helpful names, but I
can't think that sticking _<mode>_<type>_Parameter on the end of every
parameter of a procedure is going to help anyone.

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

Simon Wright wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> writes:
> 
> > package Foo_Package is ...
> > type Radian_Type is ...
> > procedure Calculate_Procedure (Initial_Guess_In_Float_Parameter : in
> > Float ...
> > Number_Of_Widgets_Positive_Variable : Positive;
> > Pi_Real_Constant : Constant := 3.14159;
> > Maximum_Word_Length_Positive_Constant : constant Positive := X'Last +
> > Padding;
> 
> Are you pulling our collective leg here?

Yes.

> 
> Just to take that procedure .. what happens if it turns into a Double,
> for instance?
> 
> I'm all in favour of thinking of sensible and helpful names, but I
> can't think that sticking _<mode>_<type>_Parameter on the end of every
> parameter of a procedure is going to help anyone.

I was simply making the point that those who think sticking _Type on
every type name or _Package on every package name is a Good Thing should
also think sticking _Procedure on every procedure name, _Parameter on
every parameter name, and such are also Good Things. Then I threw in
mode and type information to make it even more unworkable.

These conventions (and The_ on every parameter name is the same thing,
only worse) are really work-arounds to having to think about names.
While not thinking is popular, it is not a good way to develop software.

I'm disheartened that only 2 of us find my proposal unsatisfactory.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail

Re: on package naming, should the word "_pkg" be part of it?

[Brian Rogoff]

On Sun, 7 Oct 2001, Jeffrey Carter wrote:
> I was simply making the point that those who think sticking _Type on
> every type name or _Package on every package name is a Good Thing should
> also think sticking _Procedure on every procedure name, _Parameter on
> every parameter name, and such are also Good Things.

No, but arguing with absolutists who post straw man proposals to disparage
others opinions is usually a waste of time, so likely those who do favor
such redundancies in Ada decided that responding would be like discussing
religion with a true believer, or politics with a Marxist or an
Objectivist; in other words, pissing in the wind.

Perhaps, when you show that you really have thoughtfully considered the
pros and cons of such a naming convention, discussion will be posssible,
but I sure won't hold my breath. This entire issue of naming conventions,
like the issue of use clauses, has been discussed here ad-nauseum. Learn
to accept the fact that some others don't share your views, and that maybe,
just maybe, they aren't imbeciles.

-- Brian

Re: on package naming, should the word "_pkg" be part of it?

[Stephen Leake]

Jeffrey Carter <jrcarter@acm.org> writes:

> I was simply making the point that those who think sticking _Type on
> every type name or _Package on every package name is a Good Thing should
> also think sticking _Procedure on every procedure name, _Parameter on
> every parameter name, and such are also Good Things. 

Hmm. Stating what I "should" think is not very productive; better to
ask what I _do_ think, and why.

I use _Type. The reason is that types and objects share the same
namespace, yet the most reasonable name for an object and a type is
the same:

type Car is record ... end record;

Car : Car;

This is natural, but illegal. The easiest (for _me_, not for
everyone!) way to resolve it is to add some "noise" to either the
object or the type. Since the object name will appear more often than
the type, I add noise to the type:

type Car_Type is record ... end record;

Car : Car_Type;

> Then I threw in mode and type information to make it even more
> unworkable.

There is simply no reason to add more noise; Ada is fine just the way
it is.

> These conventions (and The_ on every parameter name is the same
> thing, only worse) are really work-arounds to having to think about
> names. 

No, they are work-arounds for a language design choice; types and
objects could have distinct name spaces. I'm not clear why they don't,
but I don't spend much time worrying about it.

> While not thinking is popular, it is not a good way to develop
> software.

This is true.

> I'm disheartened that only 2 of us find my proposal unsatisfactory.

I agree with Brian's response here; your first post was simply not worth
responding to. You need to listen to what we are saying, not just tell
us we are wrong.

-- 
-- Stephe

Re: on package naming, should the word "_pkg" be part of it?

[Francisco Javier Loma Daza]

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


I use the following name convention


package Car is

	type Object is record .. end record;

	procedure Oper1(this: Object);

end Car;

and then

	a_car: Car.Object;

I like this way because generic instantiation keeps very readable

	package Car_List is new Generic_List(Car.Object);

and then

	a_car_list: Car_List.Object;

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Mon, 08 Oct 2001 18:11:53 +0200, Francisco Javier Loma Daza
<Francisco.Loma@isotrol.com> wrote:

Francisco

Try this naming convention using generic instantiation of a generic
child package. As far as I can remember, there are serious problems
with attempting this, hence my comment earlier on this thread.

>I use the following name convention
>
>
>package Car is
>
>	type Object is record .. end record;
>
>	procedure Oper1(this: Object);
>
>end Car;
>
>and then
>
>	a_car: Car.Object;
>
>I like this way because generic instantiation keeps very readable
>
>	package Car_List is new Generic_List(Car.Object);
>
>and then
>
>	a_car_list: Car_List.Object;

Re: on package naming, should the word "_pkg" be part of it?

[Francisco Javier Loma Daza]

>  John McCabe wrote:
> 
> Try this naming convention using generic instantiation of a generic
> child package. As far as I can remember, there are serious problems
> with attempting this, hence my comment earlier on this thread.
> 

Could you elaborate please? I use this naming convention in my diploma
project, and it works rather well for me.

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Tue, 09 Oct 2001 09:41:45 +0200, Francisco Javier Loma Daza
<Francisco.Loma@isotrol.com> wrote:

>
>>  John McCabe wrote:
>> 
>> Try this naming convention using generic instantiation of a generic
>> child package. As far as I can remember, there are serious problems
>> with attempting this, hence my comment earlier on this thread.
>> 
>
>Could you elaborate please? I use this naming convention in my diploma
>project, and it works rather well for me.

I'm trying to get hold of one - it was actually a colleague at my old
job who discovered the problem but he hasn't found his example yet :-)

I believe the problem occurs if you have something like:

generic
   ....
package Parent is
   type Object is tagged
      record
         ...
      end record;

   procedure Op_1 (This : in Object);
end Parent;

then

with Parent;
generic
   ...
package Parent.Child is
   type Object is new Parent.Object with
      record
         ...
      end record;

   procedure Op_1 (This : in Object);
end Parent.Child;

It may be a scoping issue because in Parent.Child you have direct
visibilty of the 'Object' type in Parent. It may not be a problem at
this point, but possibly when another 'class' instantiates both of
these packages.

If/when I get a firm example I'll let you know.

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Wed, 10 Oct 2001 08:04:10 GMT, john.mccabe@emrad.com.nospam (John
McCabe) wrote:

Francisco

I've just been reminded of where the problem lies with respect to the
use of Object as a 'class' name (with thanks to Martin Ellerker).

Consider the following Parent and Child classes (similar to what I
mentioned in my earlier message):

File: GParent.ads
-----------------
generic
package GParent is
   type Object is abstract tagged null record;
end GParent;

File: GParent-GChild.ads
------------------------
with GParent;
generic
package GParent.GChild is
   type Object is new GParent.Object with null record;
end GParent.GChild;

Separate library level instantiations are provided as follows:

File: IParent.ads
-----------------
with GParent;
package IParent is new GParent;

File: IChild.ads
----------------
with IParent;
with GParent.GChild;
package IChild is new IParent.GChild;

So far so good. A test program as follows compiles and runs without
error (unless I've typed something in wrongly)

File: TestG.adb
---------------
with IChild;
procedure TestG is
begin
   null;
end TestG;


Now, however, if you then have a third level of Generic class, say..

File: GParent-GChild-GGChild.ads
--------------------------------
with GParent.GChild;
generic
package GParent.GChild.GGChild is
   type Object is new GParent.GChild.Object with null record;
end GParent.GChild.GGChild;

and instantiate it with:

File: IGChild.ads
-----------------
with IChild;
with GParent.GChild.GGChild;
package IGChild is new IChild.GGChild;

and change the test program to:

File: TestG.adb
---------------
with IGChild;      -- Change to IGChild from IChild.
procedure TestG is
begin
   null;
end TestG;

we get the error:

igchild.ads:3:01: instantiation error at gparent-gchild-ggchild.ads:4
igchild.ads:3:01: "GChild" not declared in "IParent".

The cause of this is the explicit reference in line 4 of
GParent-GChild-GGChild.ads to GParent.GChild.Object. Since IChild is
the instantiation of GChild, it is IChild that, at this point,
declares the GGChild 'class' we're interested in, not GParent.GChild.

We could attempt to use the child-to-parent visibility rules to allow
use to change GParent.Object and GParent.GChild.Object into just
Object and Object, but then the scoping rules cause problems with
errors:

gparent-gchild.ads:4:24: object "Object" cannot be used before end of
its declaration
gparent-gchild-ggchild.ads:4:24: object "Object" cannot be used before
end of its declaration

So there you go.

I realise this may seem like a complex and unrealistic example, but
consider (the implementation we were looking at) the use of lists...

At the Parent level you have a generic that defines a container for a
type.
At the Child level you have a linked list of objects of the type.
At the grandchild level you have a doubly-linked list of object of the
type.
At the great-grandchild you have an ordered list of objects of the
type.

Similarly for Container - Tree - AVL Tree.

There are, of course different implementations possible which may
avoid this problem but, ultimately, the easiest way is to *avoid*
using "Object" as the name of a 'class'.

Hope this helps. The examples were compiled with GNAT 3.13p on Windows
2000.

Re: on package naming, should the word "_pkg" be part of it?

[Francisco Javier Loma Daza]

On Wed, 10 Oct 2001, john.mccabe@emrad.com.nospam (John McCabe) wrote:
> Date: Wed, 10 Oct 2001 09:47:04 GMT
> To: comp.lang.ada@ada.eu.org
> From: john.mccabe@emrad.com.nospam (John McCabe)
> Reply-To: comp.lang.ada@ada.eu.org
> Sender: comp.lang.ada-admin@ada.eu.org
> Subject: Re: on package naming, should the word "_pkg" be part of it?
> 
> On Wed, 10 Oct 2001 08:04:10 GMT, john.mccabe@emrad.com.nospam (John
> McCabe) wrote:
> 
> Francisco
> 
> I've just been reminded of where the problem lies with respect to the
> use of Object as a 'class' name (with thanks to Martin Ellerker).
> 
> Consider the following Parent and Child classes (similar to what I
> mentioned in my earlier message):
> 
> File: GParent.ads
> -----------------
> generic
> package GParent is
>    type Object is abstract tagged null record;
> end GParent;
> 
> File: GParent-GChild.ads
> ------------------------
> with GParent;
> generic
> package GParent.GChild is
>    type Object is new GParent.Object with null record;
> end GParent.GChild;
> 
> Separate library level instantiations are provided as follows:
> 
> File: IParent.ads
> -----------------
> with GParent;
> package IParent is new GParent;
> 
> File: IChild.ads
> ----------------
> with IParent;
> with GParent.GChild;
> package IChild is new IParent.GChild;
> 
> So far so good. A test program as follows compiles and runs without
> error (unless I've typed something in wrongly)
> 
> File: TestG.adb
> ---------------
> with IChild;
> procedure TestG is
> begin
>    null;
> end TestG;
> 
> 
> Now, however, if you then have a third level of Generic class, say..
> 
> File: GParent-GChild-GGChild.ads
> --------------------------------
> with GParent.GChild;
> generic
> package GParent.GChild.GGChild is
>    type Object is new GParent.GChild.Object with null record;
> end GParent.GChild.GGChild;
> 
> and instantiate it with:
> 
> File: IGChild.ads
> -----------------
> with IChild;
> with GParent.GChild.GGChild;
> package IGChild is new IChild.GGChild;
> 
> and change the test program to:
> 
> File: TestG.adb
> ---------------
> with IGChild;      -- Change to IGChild from IChild.
> procedure TestG is
> begin
>    null;
> end TestG;
> 
> we get the error:
> 
> igchild.ads:3:01: instantiation error at gparent-gchild-ggchild.ads:4
> igchild.ads:3:01: "GChild" not declared in "IParent".
> 
> The cause of this is the explicit reference in line 4 of
> GParent-GChild-GGChild.ads to GParent.GChild.Object. Since IChild is
> the instantiation of GChild, it is IChild that, at this point,
> declares the GGChild 'class' we're interested in, not GParent.GChild.
> 
> We could attempt to use the child-to-parent visibility rules to allow
> use to change GParent.Object and GParent.GChild.Object into just
> Object and Object, but then the scoping rules cause problems with
> errors:
> 
> gparent-gchild.ads:4:24: object "Object" cannot be used before end of
> its declaration
> gparent-gchild-ggchild.ads:4:24: object "Object" cannot be used before
> end of its declaration
> 
> So there you go.
> 

	I would use the following to desambiguate

-- with GParent.GChild; -- this is not needed
generic
package GParent.GChild.GGChild is
    type Object is new GChild.Object with null record;
end GParent.GChild.GGChild;
 
That is the schema I actually use. For anothe level of genericity

generic
package GParent.GChild.GGChild.GGGChild is
	type Object is new GGChild.Object with null record;
	subtype Class is Object'Class;
	type Handle is access all Object'Class;
	type Pointer is access all Object;

	--another useful (sometimes) trick 
	package Parent renames GGChild;
	-- and then use  Parent.Object to call parent methods
end; 

and so for.

Re: on package naming, should the word "_pkg" be part of it?

[Francisco Javier Loma Daza]

On Wed, 10 Oct 2001, john.mccabe@emrad.com.nospam (John McCabe) wrote:
> Date: Wed, 10 Oct 2001 09:47:04 GMT
> To: comp.lang.ada@ada.eu.org
> From: john.mccabe@emrad.com.nospam (John McCabe)
> Reply-To: comp.lang.ada@ada.eu.org
> Sender: comp.lang.ada-admin@ada.eu.org
> Subject: Re: on package naming, should the word "_pkg" be part of it?
> 
> On Wed, 10 Oct 2001 08:04:10 GMT, john.mccabe@emrad.com.nospam (John
> McCabe) wrote:
> 
> Francisco
> 
> I've just been reminded of where the problem lies with respect to the
> use of Object as a 'class' name (with thanks to Martin Ellerker).
> 
> Consider the following Parent and Child classes (similar to what I
> mentioned in my earlier message):
> 
> File: GParent.ads
> -----------------
> generic
> package GParent is
>    type Object is abstract tagged null record;
> end GParent;
> 
> File: GParent-GChild.ads
> ------------------------
> with GParent;
> generic
> package GParent.GChild is
>    type Object is new GParent.Object with null record;
> end GParent.GChild;
> 
> Separate library level instantiations are provided as follows:
> 
> File: IParent.ads
> -----------------
> with GParent;
> package IParent is new GParent;
> 
> File: IChild.ads
> ----------------
> with IParent;
> with GParent.GChild;
> package IChild is new IParent.GChild;
> 
> So far so good. A test program as follows compiles and runs without
> error (unless I've typed something in wrongly)
> 
> File: TestG.adb
> ---------------
> with IChild;
> procedure TestG is
> begin
>    null;
> end TestG;
> 
> 
> Now, however, if you then have a third level of Generic class, say..
> 
> File: GParent-GChild-GGChild.ads
> --------------------------------
> with GParent.GChild;
> generic
> package GParent.GChild.GGChild is
>    type Object is new GParent.GChild.Object with null record;
> end GParent.GChild.GGChild;
> 
> and instantiate it with:
> 
> File: IGChild.ads
> -----------------
> with IChild;
> with GParent.GChild.GGChild;
> package IGChild is new IChild.GGChild;
> 
> and change the test program to:
> 
> File: TestG.adb
> ---------------
> with IGChild;      -- Change to IGChild from IChild.
> procedure TestG is
> begin
>    null;
> end TestG;
> 
> we get the error:
> 
> igchild.ads:3:01: instantiation error at gparent-gchild-ggchild.ads:4
> igchild.ads:3:01: "GChild" not declared in "IParent".
> 
> The cause of this is the explicit reference in line 4 of
> GParent-GChild-GGChild.ads to GParent.GChild.Object. Since IChild is
> the instantiation of GChild, it is IChild that, at this point,
> declares the GGChild 'class' we're interested in, not GParent.GChild.
> 
> We could attempt to use the child-to-parent visibility rules to allow
> use to change GParent.Object and GParent.GChild.Object into just
> Object and Object, but then the scoping rules cause problems with
> errors:
> 
> gparent-gchild.ads:4:24: object "Object" cannot be used before end of
> its declaration
> gparent-gchild-ggchild.ads:4:24: object "Object" cannot be used before
> end of its declaration
> 
> So there you go.


	The problem is not in naming 'Object' the types, but the extra level
(innecesary) of qualification for the parent object name
	GParent.GChild.Object new GChild.Object will work. Escecifying
Gparent.G... references to generic (uninstanciated) package.

	Try to name with different names all the types
gParent.Object1
gParent.gChild.Object2
gparent.gChild.ggChild.Object3

and the problem still alive, so the problem is not this naming convention.
I'm wrong?

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Wed, 10 Oct 2001 12:27:49 +0200, Francisco Javier Loma Daza
<Francisco.Loma@isotrol.com> wrote:

>	The problem is not in naming 'Object' the types, but the extra level
>(innecesary) of qualification for the parent object name
>	GParent.GChild.Object new GChild.Object will work.

You appear to be absolutely correct in your other message. I have
chatted to my colleague about this. It would appear that our discovery
of this problem was that we were automatically generating our code
from Rational Rose which, unusually in this case, appears to have
managed to do its name resolution correctly! It's unfortunate that it
didn't realise the code it was producing was useless without
modification.


Anyway - I appreciate you pointing this out, you learn something new
every day, huh :-)

>Escecifying

What's "escecifying"?

Re: on package naming, should the word "_pkg" be part of it?

[Francisco Javier Loma Daza]

On Wed, 10 Oct 2001, john.mccabe@emrad.com.nospam (John McCabe) wrote:
> Date: Wed, 10 Oct 2001 12:50:15 GMT
> To: comp.lang.ada@ada.eu.org
> From: john.mccabe@emrad.com.nospam (John McCabe)
> Reply-To: comp.lang.ada@ada.eu.org
> Sender: comp.lang.ada-admin@ada.eu.org
> Subject: Re: on package naming, should the word "_pkg" be part of it?
> 
> On Wed, 10 Oct 2001 12:27:49 +0200, Francisco Javier Loma Daza
> <Francisco.Loma@isotrol.com> wrote:
> 
> >   The problem is not in naming 'Object' the types, but the extra level
> >(innecesary) of qualification for the parent object name
> >   GParent.GChild.Object new GChild.Object will work.
> 
> You appear to be absolutely correct in your other message. I have
> chatted to my colleague about this. It would appear that our discovery
> of this problem was that we were automatically generating our code
> from Rational Rose which, unusually in this case, appears to have
> managed to do its name resolution correctly! It's unfortunate that it
> didn't realise the code it was producing was useless without
> modification.
> 
> 
> Anyway - I appreciate you pointing this out, you learn something new
> every day, huh :-)

    Me too :-)

> 
> >Escecifying
> 
> What's "escecifying"?


    Well :) my english is really sloopy ... What I meant was that if you
type
    type Object is new GParent.GChild.Object is ...

you are referencig to package GParent, and that package is a generic one.

Re: on package naming, should the word "_pkg" be part of it?

[Robert*]

In article <ud73ymbha.fsf@gsfc.nasa.gov>, Stephen says...
>
 


>I use _Type. The reason is that types and objects share the same
>namespace, yet the most reasonable name for an object and a type is
>the same:
>
>type Car is record ... end record;
>
>Car : Car;
>
>This is natural, but illegal. 
....

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

 
I also like the _type thing for same reason as above. (in C, many use _t ).

Note in languages that are case sensitive, like Java, the convention is
to use an Upper case first littler for a class name (at leat in Java that
is what everyone does). So, the above is written like this:

Car car;


problem solved :)  

Re: on package naming, should the word "_pkg" be part of it?

[Matthew Woodcraft]

Robert*@ <Robert_member@newsguy.com> writes:

> I also like the _type thing for same reason as above. (in C, many use _t ).

Though as the Single Unix Specification have reserved all identifiers
ending in _t (!), this might be a dangerous practice.

The joys of a flat namespace...

-M-

Re: on package naming, should the word

[Ted Dennison]

In article <ud73ymbha.fsf@gsfc.nasa.gov>, Stephen Leake says...
>
>I use _Type. The reason is that types and objects share the same
>namespace, yet the most reasonable name for an object and a type is
>the same:
>
>type Car is record ... end record;
>
>Car : Car;
>
>This is natural, but illegal. The easiest (for _me_, not for

No, there is a difference. Type "Car" supposedly can be used to represent any
car imaginable (as far as your program is concerned, anyway). The object, on the
other hand, represents a specific car (or a car being used for a specific
purpose), and thus deserves a more specific name than the overly-general "Car".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word "_pkg" be part of it?

[Vincent Marciante]

Stephen Leake wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> writes:
> 
> > I was simply making the point that those who think sticking _Type on
> > every type name or _Package on every package name is a Good Thing should
> > also think sticking _Procedure on every procedure name, _Parameter on
> > every parameter name, and such are also Good Things.
> 
> Hmm. Stating what I "should" think is not very productive; better to
> ask what I _do_ think, and why.
> 
> I use _Type. The reason is that types and objects share the same
> namespace, yet the most reasonable name for an object and a type is
> the same:
> 
> type Car is record ... end record;
> 
> Car : Car;
> 
> This is natural, but illegal. The easiest (for _me_, not for
> everyone!) way to resolve it is to add some "noise" to either the
> object or the type. Since the object name will appear more often than
> the type, I add noise to the type:
> 
> type Car_Type is record ... end record;
> 
> Car : Car_Type;

If you declare the type in another package then you do not 
have to add any "noise" to the simple type name.  

By the way, your argument above implies that you are expecting
to any have one object of the type.  In my experience, It is 
rare to have only one object of a type - I would not add _type
to all type definitions as a convention just to make the rare
case "easy" to deal with.


Vincent Marciante

Re: on package naming, should the word "_pkg" be part of it?

[Stephen Leake]

Vincent Marciante <marciant_remove@li.net> writes:

> > <snip> 
> > type Car is record ... end record;
> > 
> > Car : Car;
> > 
> > This is natural, but illegal. The easiest (for _me_, not for
> > everyone!) way to resolve it is to add some "noise" to either the
> > object or the type. Since the object name will appear more often than
> > the type, I add noise to the type:
> > 
> > type Car_Type is record ... end record;
> > 
> > Car : Car_Type;
> 
> If you declare the type in another package then you do not 
> have to add any "noise" to the simple type name.  

True. But I'm mostly thinking of parameters for primitive operations
on a type (see below). The above is just the simplest example that
shows the Ada limitation (merged object and type namespace).

> By the way, your argument above implies that you are expecting to
> any have one object of the type. In my experience, It is rare to
> have only one object of a type - I would not add _type to all type
> definitions as a convention just to make the rare case "easy" to
> deal with.

A better example would be:

package Cars is 

    type Car_Type is ...;

    procedure Foo (Car : in Car_Type);

    procedure Bar (Car : in Car_Type);

end package Cars;

You can come up with alternatives to any individual use of _Type. But
in my experience, _Type is the only alternative that works in _all_
situations; generic instantiations in particular get very fussy about
names.

-- 
-- Stephe

Re: on package naming, should the word "_pkg" be part of it?

[Vincent Marciante]

Stephen Leake wrote:
> 
> Vincent Marciante <marciant_remove@li.net> writes:
> 
> > > <snip>
> >
> > If you declare the type in another package then you do not
> > have to add any "noise" to the simple type name.
> 
> True. But I'm mostly thinking of parameters for primitive operations
> on a type (see below). The above is just the simplest example that
> shows the Ada limitation (merged object and type namespace).
> 
<snip>
> 
> A better example would be:
> 
> package Cars is
> 
>     type Car_Type is ...;
> 
>     procedure Foo (Car : in Car_Type);
> 
>     procedure Bar (Car : in Car_Type);
> 
> end package Cars;
> 
> You can come up with alternatives to any individual use of _Type. But
> in my experience, _Type is the only alternative that works in _all_
> situations; generic instantiations in particular get very fussy about
> names.
> 
> --
> -- Stephe

I do not know the situation that gives trouble with generic
instantiation.
The following is legal.  What is the problematic situation?

generic
    type Car is private;
package Cars is 
    procedure Foo (Car : in Cars.Car);
    procedure Bar (Car : in Cars.Car);
end Cars;

package body Cars is 
    procedure Foo (Car : in Cars.Car) is
    begin
        null;
    end;
    procedure Bar (Car : in Cars.Car) is
    begin
        null;
    end;
end Cars;

with cars;
procedure cars_test is
    type car is new boolean;
    package cars is new standard.cars(car);
    car_1 : car;
    car_2 : car;
begin
    cars.foo(car_1);
    cars.bar(car_2);
end cars_test;

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

Stephen Leake wrote:
> 
> I use _Type. The reason is that types and objects share the same
> namespace, yet the most reasonable name for an object and a type is
> the same:
> 
> type Car is record ... end record;
> 
> Car : Car;
> 
> This is natural, but illegal. The easiest (for _me_, not for
> everyone!) way to resolve it is to add some "noise" to either the
> object or the type. Since the object name will appear more often than
> the type, I add noise to the type:

No, it's not natural. What might be natural is

VIN_ABC1234567JKLK67 : Car;

or

Car : Chevy_1957;

More realistically,

Current_Vehicle : Car;

Even this is incorrect. Current_Vehicle is not a car, it is a collection
of information about a car:

Current_Vehicle : Car_Info;

The developer thinks, "This type is a collection of information about
cars, so its name should be Collection_Of_Information_About_Cars, or
Car_Info for short." Or something like that.

Further, there is generally no problem with object names, since objects
of the type are generally not declared in the same scope:

Car : Car_Handler.Car;

It is parameter names defined in the same scope that are perceived as a
problem. In many cases, even parameter names are not a problem. When
inserting into a list, Into seems a better parameter name than List;
when iterating over a structure, Over seems better than List, Queue, or
Stack, and so on.

Maybe _Info is still noise, but it seems like more reasoned noise than
_Type. If the object is simply to put some noise on the end of type
names to distinguish them from parameter names, then _T seems as good as
any other noise.

Another "solution" I have seen is

package Types is
   type Bicycle is ...

   type Car is ...

   type Number is ...

   type Rainfall_Sensor_Reading is ...

   ...
end Types;

with Types;
package Functions is
   function Bicycle_Speed (Bicycle : Types.Bicycle) return Types.Number;

   function Car (Number : Types.Number) return Types.Car;

   function Car_Speed (Car : Types.Car) return Types.Number;

   ...
end Functions;

Never a name problem!

Even noise is better than this.

-- 
Jeffrey Carter

Re: on package naming, should the word "_pkg" be part of it?

[Stephen Leake]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> Stephen Leake wrote:
> > 
> > I use _Type. The reason is that types and objects share the same
> > namespace, yet the most reasonable name for an object and a type is
> > the same:
> > 
> > type Car is record ... end record;
> > 
> > Car : Car;
> > 
> > This is natural, but illegal. The easiest (for _me_, not for
> > everyone!) way to resolve it is to add some "noise" to either the
> > object or the type. Since the object name will appear more often than
> > the type, I add noise to the type:
> 
> No, it's not natural. 

Well, it is for me, in the situations I have encounterd so far.
Celebrate diversity :).

> What might be natural is
> 
> VIN_ABC1234567JKLK67 : Car;

That's solving a different problem than I had in mind; you are
assuming you need one named Ada object per physical car. My example is
way too short for you to jump to this conclusion. See my other post
for a better example (primitive operations of a type).

> Car : Chevy_1957;

Still another problem; each model of car should have a different type.

> More realistically,
> 
> Current_Vehicle : Car;

Still another problem; iterating thru a collection.

> Even this is incorrect. Current_Vehicle is not a car, it is a
> collection of information about a car:
> 
> Current_Vehicle : Car_Info;

Actually, I would have assumed it was a collection of information
about a vehicle, which might not be a 'car':

Vehicle_Info : Vehicle_Info_Type;

:).

> The developer thinks, "This type is a collection of information
> about cars, so its name should be
> Collection_Of_Information_About_Cars, or Car_Info for short." Or
> something like that.

Car_Info : Car_Info_Type;

> Further, there is generally no problem with object names, since
> objects of the type are generally not declared in the same scope:
> 
> Car : Car_Handler.Car;

Well, sometimes this is true, but not _always_. In particular,
primitive operations of tagged types _must_ be declared in the same
scope as the type. And I don't want a separate convention for that!

> It is parameter names defined in the same scope that are perceived
> as a problem. In many cases, even parameter names are not a problem.
> When inserting into a list, Into seems a better parameter name than
> List; when iterating over a structure, Over seems better than List,
> Queue, or Stack, and so on.

Not to me. Sometimes you can make the function call read more
"naturally" with parameter names like "Into". But the body reads very
oddly, unless you use renames on the parameters, which is error-prone.

> Maybe _Info is still noise, but it seems like more reasoned noise
> than _Type. If the object is simply to put some noise on the end of
> type names to distinguish them from parameter names, then _T seems
> as good as any other noise.

Yes, _T is a good choice. I'm not entirely sure why I originally chose
_Type instead of _T. At this point, there are many in the Ada comunity
that use _Type; I don't know of any that use _T. So _Type wins.

> Another "solution" I have seen is
> 
> <snip non-tagged example>
> 
> Never a name problem!

Unless you need tagged types and primitive operations.

As I said in another post, you can come up with alternate solutions to
any particular instance of _Type. But _Type is the simplest one that works
_everywhere_. It's nice to have one naming convention, rather than several.

Another strong argument here is that you can get used to any style,
after a while. The exact details of the style matter far less than
having a consistent style in the first place.

For this particular style question, Ada imposes a constraint; objects
and types share a namespace. Any solution to this constraint is
acceptable. I like _Type because it is mindless (I have plenty of
other things to think about), and works _everywhere_. But if I was on
a project that had a different convention, I would adapt (although,
sometimes resistance is _not_ useless :).

-- 
-- Stephe

Re: on package naming, should the word "_pkg" be part of it?

[Brian Rogoff]

On 8 Oct 2001, Stephen Leake wrote:
[... snip lots of things from Stephen I agree with ...]
> Yes, _T is a good choice. I'm not entirely sure why I originally chose
> _Type instead of _T. At this point, there are many in the Ada comunity
> that use _Type; I don't know of any that use _T. So _Type wins.

I experimented with a style like this for a while, and it works fine.
Also, if you accept the hypothesis that there is typically just one main
type per module (yeah, I know, an Eiffelesque hypothesis) you can just use
"T" for the type and use qualified names so that the package name provides
the meaningful part.

This kind of style is used in some Modula-3 libraries I've seen, and
somewhat in (OCa)ML.

[... snip ...]

> As I said in another post, you can come up with alternate solutions to
> any particular instance of _Type. But _Type is the simplest one that works
> _everywhere_. It's nice to have one naming convention, rather than several.

Exactly, and the reason, as you point out below, is that types and objects
share a namespace, and this convention partitions the namespace.

> Another strong argument here is that you can get used to any style,
> after a while. The exact details of the style matter far less than
> having a consistent style in the first place.

In fact, I wouldn't want to work with someone who wasn't stylistically
labile. I've already spent too much time with other C programmers who got
all fanatical about brace placement. It seems that the amount of vehemence
about programming language issues is inversely proportional to their
importance :-).

-- Brian

Re: on package naming, should the word

[Ted Dennison]

In article <20011008121837.C3733-100000@shell5.ba.best.com>, Brian Rogoff
says...
>
>I experimented with a style like this for a while, and it works fine.
>Also, if you accept the hypothesis that there is typically just one main
>type per module (yeah, I know, an Eiffelesque hypothesis) you can just use
>"T" for the type and use qualified names so that the package name provides
>the meaningful part.

In that case, I think you do indeed have to arbitrarily pick something, and
_Type would qualify as "something" I guess. :-). 

Just don't use it anywhere else, or we'll have to rumble. Its mechanical pencils
at high noon. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Richard Riehle]

Ted Dennison wrote:

> Just don't use it anywhere else, or we'll have to rumble. Its mechanical pencils
> at high noon. :-)

It has been suggested that the reason we have taken away the coding sheets
and replaced them with keyboards is because we discovered we could not
trust most programmers with sharp instruments. Put the pencil on the floor, now,
Ted. Step away from the pencil, now, Ted.  :-)

Richard Riehle

Re: on package naming, should the word "_pkg" be part of it?

[Darren New]

> Also, if you accept the hypothesis that there is typically just one main
> type per module (yeah, I know, an Eiffelesque hypothesis) you can just use
> "T" for the type and use qualified names so that the package name provides
> the meaningful part.


What about endings for "T", "access T", "T'Class", and so on? If I have
"Car.T", what would I call a pointer to that? Or the type that's a
class-wide type for that?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: on package naming, should the word "_pkg" be part of it?

[Brian Rogoff]

On Tue, 9 Oct 2001, Darren New wrote:
> > Also, if you accept the hypothesis that there is typically just one main
> > type per module (yeah, I know, an Eiffelesque hypothesis) you can just use
> > "T" for the type and use qualified names so that the package name provides
> > the meaningful part.
>
> What about endings for "T",

I don't understand.

> "access T",

Depends on the program. I've used Ref_T, but T is a short enough type name
that I don't think it's necessary to name the pointer unless you need the
type and the pointer simultaneously a lot. For some reason, in my Ada
code, unlike my C code, that isn't common. If you want to expose a type
which has is represented by an access type, call it T.

> "T'Class", and so on?

Same kind of answer as above.

Read the antecedent part of my if-then. "If you only have one main type in
the module, then ...". I didn't claim that this is a universal, though it
can work a lot of the time. The meta idea is that the type name is
completely generic, like naming tagged types "Class" (hmmm) or "Object"
(awful) and the meaningful part of the name is pushed onto the package
name.

A nastier objection is that many modules have more than one exported type,
and not even one that can be called the "main" one. In that case you can
still use an "_T" suffix, but since those Ada programmers who prefer a
suffix have gravitated towards "_Type" I think that it makes more sense to
just use that if you are so inclined.

-- Brian

Re: on package naming, should the word "_pkg" be part of it?

[Robert*]

In article <20011009174047.V16689-100000@shell5.ba.best.com>, Brian says...
>
 
>The meta idea is that the type name is
>completely generic, like naming tagged types "Class" (hmmm) or "Object"
>(awful) and the meaningful part of the name is pushed onto the package
>name.
>
>A nastier objection is that many modules have more than one exported type,
>and not even one that can be called the "main" one. In that case you can
>still use an "_T" suffix, but since those Ada programmers who prefer a
>suffix have gravitated towards "_Type" I think that it makes more sense to
>just use that if you are so inclined.
 

I think all of the above is a side-effect of trying to make Ada look like
the other 'normal' OO languages, in which the class is the basic and
primary building block in the program, and not the package. In Ada the 
package is the basic building block in the program.

I wish the Ada95 designers would have introduced the class construct as in

Package XXX is

  Class Vehicle is
    Begin
        private i : integer;
        private name : string;
        function Vehicle is  --- the constructor
           begin
               ....
           end;
        public function get_name returns string is
                 .....
         end get_name;
     end class Vehicle;

   Class Car extends Vehicle is
      Begin
          .....
    end class Car;

    ... possibly other class declarations here or other type declarations.

end foo;

Now the above  looks and feels like the other OO languages, and would have
made it much easier for Ada to be attractive to the new generation of
programmers who want to do nothing but OO things.

I know, I know, the above would have broken backword compatibility with
Ada83, and it is mainly a cosmatic change for marketing purposes, But 
I think it would have been better to do it the above way (similar
to Delphi) and call the new langauge something else, who cares, as long as
it retains all the other good things about Ada. 

I wish I was good in language design (you probably think I am not based
on the above, right? :), but if I knew how to design languages, I would
design a new language that has all the good stuff that Ada has now, but with 
the above change in it. I bet the new language would be more popular than 
Ada95 as it stands now.

I am not saying the current tagged record is bad from technical point of view,
I think it is technically brilliant since it introduces OO to Ada with the 
least amount of changes. I am saying that making Ada look like the 
other current OO languages in that respect only, would have made it much
more popular and easier to get into it for OO programming since it would looked
and felt the same as C++ and Java and Delphi etc...

 

Re: on package naming, should the word "_pkg" be part of it?

[Brian Rogoff]

On 9 Oct 2001, it was written:
> In article <20011009174047.V16689-100000@shell5.ba.best.com>, Brian says...
> >
>
> >The meta idea is that the type name is
> >completely generic, like naming tagged types "Class" (hmmm) or "Object"
> >(awful) and the meaningful part of the name is pushed onto the package
> >name.
> >
> >A nastier objection is that many modules have more than one exported type,
> >and not even one that can be called the "main" one. In that case you can
> >still use an "_T" suffix, but since those Ada programmers who prefer a
> >suffix have gravitated towards "_Type" I think that it makes more sense to
> >just use that if you are so inclined.
>
>
> I think all of the above is a side-effect of trying to make Ada look like
> the other 'normal' OO languages, in which the class is the basic and
> primary building block in the program, and not the package. In Ada the
> package is the basic building block in the program.

Only the "T" convention, which I admit was influenced by, among other
things, my reading of "Object Oriented Software Construction". There's
some rule there about one type per module.

The "_Type" convention, as Stephen Leake pointed out, is simply a convention
for putting type names in a different namespace. "_T" or even "_Blech"
works fine, but as I said "_Type" is widely used and we don't work in a
vacuum so if you must choose for real programs I'd strongly advise you to
choose that. I just played around with the "T" convention in code that I
never planned to release to see how I liked it.

As far as an "object<dot>method" syntax for classes goes, I don't think
this is a big deal, but you could be right. I'm relatively insensitive
to syntax choices, but apparently lots of people aren't. I think Tucker
Taft proposed a more conventional syntax for "method" calls for an Ada 0X
but I forget where I saw it.

-- Brian

Re: on package naming, should the word "_pkg" be part of it?

[Darren New]

> As far as an "object<dot>method" syntax for classes goes, I don't think
> this is a big deal, but you could be right.

Well, it can be handy. Right now, I'm working on a system that'll have a
"profile" class-wide type and a "controller" classwide type. They're
each going to get references to each other. Unless I can figure a way
around it, this means the profile and controller will need to be
declared in the same package, and since they're both tagged, it's going
to be a mess sorting out the primitive operations.

So yeah, having an OO kind of syntax to say what's a primitive operation
of which would probably help in this case.

It would be nice to have dynamically-dispatched protected objects and
tasks, as well.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: on package naming, should the word "_pkg" be part of it?

[tmoran]

>"profile" class-wide type and a "controller" classwide type. They're
>...
>So yeah, having an OO kind of syntax to say what's a primitive operation
>of which would probably help in this case.
  'class is a short and sweet way to say what's a primitive operation
of which:
  procedure p(x: in Profile_Type; y : in Controller_Type'class);
  procedure q(x: in Profile_Type'class; y : in Controller_Type);
p is a primitive operation of Profile_Type
q is a primitive operation of Controller_Type

> ...  will need to be declared in the same package, and since they're
> both tagged, it's going to be a mess sorting out the primitive operations.
  IMHO, a tagged type is just another programming construct, like a
procedure or a record declaration.  Nobody would argue that there should
only be a single procedure per package and there's similarly nothing
inherently bad about multiple OO declarations in a single package.
  There are general considerations about a package being broken up
before it's too big to understand.  Those considerations of course may
lead to a single tagged type/package.  But it's also possible to take a
set of things that make sense together and fragment them into a bunch of
hard-to-relate pieces.  Sometimes it's better to put a closely related
group of things into a single package even if the package gets larger
than usual and contains more than one tagged type declaration.
(Assuming, of course, that your programming language allows you a
choice.)

Re: on package naming, should the word "_pkg" be part of it?

[Darren New]

tmoran@acm.org wrote:
> 
> >"profile" class-wide type and a "controller" classwide type. They're
> >...
> >So yeah, having an OO kind of syntax to say what's a primitive operation
> >of which would probably help in this case.
>   'class is a short and sweet way to say what's a primitive operation
> of which:
>   procedure p(x: in Profile_Type; y : in Controller_Type'class);
>   procedure q(x: in Profile_Type'class; y : in Controller_Type);
> p is a primitive operation of Profile_Type
> q is a primitive operation of Controller_Type

Correct! Forgive this novice! :-) My brain is all aswirl today.

> > ...  will need to be declared in the same package, and since they're
> > both tagged, it's going to be a mess sorting out the primitive operations.
>   IMHO, a tagged type is just another programming construct, like a
> procedure or a record declaration.  Nobody would argue that there should
> only be a single procedure per package and there's similarly nothing
> inherently bad about multiple OO declarations in a single package.

Right. I just forgot that you need to put 'class on the parameters that
weren't supposed to cause dispatching. My bad.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: on package naming, should the word "_pkg" be part of it?

[Larry Kilgallen]

In article <9q09d801073@drn.newsguy.com>, Robert*@ <Robert_member@newsguy.com> writes:

> I am not saying the current tagged record is bad from technical point of view,
> I think it is technically brilliant since it introduces OO to Ada with the 
> least amount of changes. I am saying that making Ada look like the 
> other current OO languages in that respect only, would have made it much
> more popular and easier to get into it for OO programming since it would looked
> and felt the same as C++ and Java and Delphi etc...

I don't believe making Ada look like other languages is an inherent
benefit, especially where it is different from other languages.  Those
who move to Ada should be encouraged to think in Ada terms rather than
trying to mimic other languages.

Quality of the average Ada program is more important than market share.

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On 9 Oct 2001 18:48:24 -0700, Robert*@ <Robert_member@newsguy.com>
wrote:

>I wish the Ada95 designers would have introduced the class construct as in

Me too but why not just:

Class XXX is
   ...

etc?

The package mechanism had been in place for over 10 years as a method
if encapsulation and so on. While I can see that the use of tagged
types is an impressively versatile means of implementing OO features,
I have found that, where OO implementations are required, the 'class'
is generally mimicked by using a package with a single tagged type and
its primitive operations.

So instead of:

package XXXs is
   type XXX is abstract tagged null record;
   procedure DoSomething (This : in XXX);
   procedure AClassOperation;
end XXXs;

package YYYs is
   type YYY is new XXX with
      record
         Item_1 : Integer;
      end record;
   ClassItem : Integer;
end YYYs;

why not have something like:

class XXX is
   procedure DoSomething;
   procedure AClassOperation is classwide;
end XXX;

class YYY extends XXX is
   procedure DoSomething;
   Item_1 : Integer;
   ClassItem : Integer is classwide; -- Use classwide, not static!!!
end YYY;

So essentially a 'class' is just a package with an implicit tagged
type. Surely this must have been considered, I mean, you could even
write your classes like this and easily parse it into a package with a
tagged type!


Also, having worked with a number of people on Ada projects who had
recently used Java, C++, Visual Basic etc, I think the lack of an
object.method syntax was a serious limitation to their acceptance of
Ada 95 as an OO language.

Re: on package naming, should the word "_pkg" be part of it?

[Pascal Obry]

john.mccabe@emrad.com.nospam (John McCabe) writes:

> On 9 Oct 2001 18:48:24 -0700, Robert*@ <Robert_member@newsguy.com>
> wrote:
> 
> >I wish the Ada95 designers would have introduced the class construct as in
> 
> Me too but why not just:

This issue is worked on. See AI95-00252 on 
http://www.ada-auth.org/AI-SUMMARY.HTML.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

RE: on package naming, should the word "_pkg" be part of it?

[Steven Deller]

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org
> [mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Pascal Obry
> Sent: Wednesday, October 10, 2001 11:38 AM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: on package naming, should the word "_pkg" be part of it?
> john.mccabe@emrad.com.nospam (John McCabe) writes:
>
> > On 9 Oct 2001 18:48:24 -0700, Robert*@ <Robert_member@newsguy.com>
> > wrote:
> >
> > >I wish the Ada95 designers would have introduced the class
> construct as in
> >
> > Me too but why not just:
>
> This issue is worked on. See AI95-00252 on
> http://www.ada-auth.org/AI-SUMMARY.HTML.

Pascal
AI95-00252 only discusses Object.Method as a syntactic sugar alternative to
Package.Method(Object,...)

Is there an AI dealing with defining
  class xxx
and
  class xxx extends yyy
    procedure ..
as syntactic sugar alternatives to
  package <hidden_name> is
    type xxx is ...

as John McCabe described?

It seems to me that would make the "sugar" sweeter :-), and seems consistent
with the object.method approach described in the AI.

Regards,
Steve
"Then, after a second or so, nothing continued to happen."
Steven Deller        Smooth Sailing LLC
410 757 6924         deller@smsail.com

Re: on package naming, should the word "_pkg" be part of it?

[Pascal Obry]

"Steven Deller" <deller@smsail.com> writes:

> Pascal
> AI95-00252 only discusses Object.Method as a syntactic sugar alternative to
> Package.Method(Object,...)

Right.

> Is there an AI dealing with defining

I don't know all the AI :) but I don't think so.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On 10 Oct 2001 17:37:58 +0200, Pascal Obry <p.obry@wanadoo.fr> wrote:

>
>john.mccabe@emrad.com.nospam (John McCabe) writes:
>
>> On 9 Oct 2001 18:48:24 -0700, Robert*@ <Robert_member@newsguy.com>
>> wrote:
>> 
>> >I wish the Ada95 designers would have introduced the class construct as in
>> 
>> Me too but why not just:
>
>This issue is worked on. See AI95-00252 on 
>http://www.ada-auth.org/AI-SUMMARY.HTML.

Interesting point by Tucker Taft:

"The other prompting factor is the continual whining that Ada 95
is out of the mainstream of OOP languages because it lacks the
object.operation syntax."

This is true - irrespective of Ada's superiority as a language when
compared to many other OO languages, very few current OO type
programmers will embrace it without the object.method syntax. It is,
simply, syntactic sugar, but it makes things so much easier for those
of use who work with combinations of Ada and e.g. Java and C++.

As far as the AIs are concerned, if anyone can point to where
something like the 'class' construct I mentioned has been discussed,
it would be most interesting. If not, does anyone feel it could be
useful and should be discussed? If so, how do we do this?

Slainthe Mhor
John

Re: on package naming, should the word "_pkg" be part of it?

[M. A. Alves]

On Wed, 10 Oct 2001, John McCabe wrote:
> . . .
>
> why not have something like:
>
> class XXX is
>    procedure DoSomething;
>    procedure AClassOperation is classwide;
> end XXX;
>
> . . .
>
> Also, having worked with a number of people on Ada projects who had
> recently used Java, C++, Visual Basic etc, I think the lack of an
> object.method syntax was a serious limitation to their acceptance of
> Ada 95 as an OO language.

Yes, Ada 95 class idiom is a bit hard, but it is ok: perhaps it is better
to leave it as it is and use other software engineering items e.g. UML to
do the OO modeling and generate Ada automatically from this.

But I think the Object.Method syntax can be added with total compatibility
with Ada 95.  It really just "sugar".  I think Tucker Taft showed this.

Personally I prefer Method(Object). I just agree that both syntaxes should
be there, if possible; and if not, stay with Method(Object) ;-)

Cheers,

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: on package naming, should the word "_pkg" be part of it?

[Robert*]

In article <mailman.1002721517.7620.comp.lang.ada@ada.eu.org>, "M. says...
>
 
>
>Yes, Ada 95 class idiom is a bit hard, but it is ok: perhaps it is better
>to leave it as it is and use other software engineering items e.g. UML to
>do the OO modeling and generate Ada automatically from this.
>

But why should I install UML on my linux box just to programin Ada? this is
more obstcles to using Ada. very few will us Ada then, less than now.

>Personally I prefer Method(Object). I just agree that both syntaxes should
>be there, if possible; and if not, stay with Method(Object) ;-)
>
 
But Method(parameters...) is not in the true spirit of OO. (yes, it is
syntax only, but syntax is important in how one thinks of things).

notice how Ada is more prodcedural in its thinking: gnathtml will generate
documentation of the code, listing all the 'files' and the 'functions' and
'procedures' in the code. Javadoc will generate documentations listing all
the 'packages' and 'classes' and 'interfaces' in the code.

So even the ada documentation is procedural oriented.


I am really interesed in seeing the objects in the code, not the functions
and procedures.

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On 10 Oct 2001 11:53:00 -0700, Robert* @ wrote:
>  
> But Method(parameters...) is not in the true spirit of OO. (yes, it is
> syntax only, but syntax is important in how one thinks of things).

Strikes me as an odd statement. Look at:

   http://www.adapower.com/articles/class.html

Preben Randhol

Re: on package naming, should the word "_pkg" be part of it?

[Robert*]

In article <slrn9sanqm.cb.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
says...
>
>On 10 Oct 2001 11:53:00 -0700, Robert* @ wrote:
>>  
>> But Method(parameters...) is not in the true spirit of OO. (yes, it is
>> syntax only, but syntax is important in how one thinks of things).
>

>Strikes me as an odd statement. Look at:
>
>   http://www.adapower.com/articles/class.html
>
 
Yes, yes. I know about the above link and have read long time ago.

As was said many times, object.method() vs. method(object); is only syntax, but
it is an important syntax difference.

We can argue this for many years to come. Technical discussions on this mean 
very little any more. At the end of the day, if you want more people to 
use Ada, Ada must implements the class construct and allow programmers 
to use object.method(). 


 

Re: on package naming, should the word "_pkg" be part of it?

[Lutz Donnerhacke]

* Robert*@ wrote:
>As was said many times, object.method() vs. method(object); is only
>syntax, but it is an important syntax difference.

Oops?

>We can argue this for many years to come. Technical discussions on this
>mean very little any more. At the end of the day, if you want more people
>to use Ada, Ada must implements the class construct and allow programmers
>to use object.method().

I do not want people to use Ada if they do not like it. They will find a
grain of salt in every line and spread bad rumors about this language.

Re: on package naming, should the word "_pkg" be part of it?

[Marin David Condic]

The language syntax cannot keep changing to suit the whims of every single
possible user. Today it would be OO-types that want object.method syntax.
Tomorrow, who else will be standing in line saying "I'd use Ada, but only if
they eliminate that begin-end thing in favor of {}"? Pretty soon, instead of
syntactic-sugar, you've got syntactic-s**t. The syntax of the language
should only be changed in the face of some fundamental flaw that makes it
impossible (or at least extremely difficult) to get some important, new
capability.

The language is what it is. If OO-programmers won't use it without
object.method and C/C++ programmers won't use it without {} or #include,
then so be it. It shouldn't be modified just because someone prefers a
different syntax.

Perhaps we can suggest writing a pre-processor?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn9sb4q1.hv.lutz@taranis.iks-jena.de...
> * Robert*@ wrote:
> >We can argue this for many years to come. Technical discussions on this
> >mean very little any more. At the end of the day, if you want more people
> >to use Ada, Ada must implements the class construct and allow programmers
> >to use object.method().
>
> I do not want people to use Ada if they do not like it. They will find a
> grain of salt in every line and spread bad rumors about this language.

Re: on package naming, should the word "_pkg" be part of it?

[Larry Kilgallen]

In article <9q4a37$npd$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> The language is what it is. If OO-programmers won't use it without
> object.method and C/C++ programmers won't use it without {} or #include,
> then so be it. It shouldn't be modified just because someone prefers a
> different syntax.

In fact, being "different" might help detect closed-minded job applicants.

Re: on package naming, should the word "_pkg" be part of it?

[Robert*]

Languages get changed all the time. If a language does not adopt it dies.

Ada itself changed. we had Ada83, then came Ada95 to add OO features becuase
that what was needed to keep Ada moving along with the current needs of
software.

C changed, C++ came from C to add OO to it.

Fortran changed. now we have fortran 90.

COBOL changed.

Java is being changed to add generics to it.

may be the word change is troubling, may the word improve is better.

The point is, if a langauge does not adopt and improve with time, it will be
left behind, and people will go use (what is seen as) more modern languages. 

Re: on package naming, should the word "_pkg" be part of it?

[David Starner]

On 11 Oct 2001 08:34:01 -0700, Robert* @ <Robert_member@newsguy.com> wrote:
> 
> Languages get changed all the time. If a language does not adopt it dies.
> 
> Ada itself changed. we had Ada83, then came Ada95 to add OO features becuase
> that what was needed to keep Ada moving along with the current needs of
> software.
> 
> C changed, C++ came from C to add OO to it.
> 
> Fortran changed. now we have fortran 90.
> 
> COBOL changed.
> 
> Java is being changed to add generics to it.

And the only one of these which had real synatic change was Fortran, and
that's because Fortran had one of the most painful syntaxs ever.
Functional changes are good; diddling with syntax makes nothing simpler
and usually annoys more people then it helps. 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

>diddling with syntax makes nothing simpler
>and usually annoys more people then it helps. 

Possibly, but very few of the people I've worked with using Ada 95
would be annoyed if the object.method syntax was included.

Re: on package naming, should the word "_pkg" be part of it?

[Ian Wild]

John McCabe wrote:
> 
> >diddling with syntax makes nothing simpler
> >and usually annoys more people then it helps.
> 
> Possibly, but very few of the people I've worked with using Ada 95
> would be annoyed if the object.method syntax was included.

I've not seen it mentioned yet, but you really need to add
at least *three* new incantations:

 -o- To attract Java programmers you need "object.method()", and
make it dispatching.

  -o- To attract C++ programmers you need a non-dispatching
"object.method()", and a dispatching "access_to_object->method()".

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Fri, 12 Oct 2001 09:07:17 GMT, Ian Wild <ian@cfmu.eurocontrol.int>
wrote:


>I've not seen it mentioned yet, but you really need to add
>at least *three* new incantations:
>
> -o- To attract Java programmers you need "object.method()", and
>make it dispatching.
>
>  -o- To attract C++ programmers you need a non-dispatching
>"object.method()", and a dispatching "access_to_object->method()".

I disagree with the last one. Consider the Ada justification for not
differentiating the dot notation between 'pointers' and objects, and I
think this should be applied to any future change of method calling.

Personally, now I'm using C++, I find the -> a pain!

Re: on package naming, should the word "_pkg" be part of it?

[Ian Wild]

John McCabe wrote:
> 
> On Fri, 12 Oct 2001 09:07:17 GMT, Ian Wild <ian@cfmu.eurocontrol.int>
> wrote:
> 
> >I've not seen it mentioned yet, but you really need to add
> >at least *three* new incantations:
> >
> > -o- To attract Java programmers you need "object.method()", and
> >make it dispatching.
> >
> >  -o- To attract C++ programmers you need a non-dispatching
> >"object.method()", and a dispatching "access_to_object->method()".
> 
> I disagree with the last one. Consider the Ada justification for not
> differentiating the dot notation between 'pointers' and objects, and I
> think this should be applied to any future change of method calling.

But you need the two different versions to allow (and, indeed, force)
the programmer to endlessly fret about the relative efficiency of
a direct non-dispatching call versus a vtable lookup.

> Personally, now I'm using C++, I find the -> a pain!

Me too, and me too.  I'd be happier if C++ had, in its early days, adopted
the then-common convention of putting the verb first, followed by a
parethesised list of actual parameters.  No wonder it never caught on.

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

John McCabe wrote:
> 
> >diddling with syntax makes nothing simpler
> >and usually annoys more people then it helps.
> 
> Possibly, but very few of the people I've worked with using Ada 95
> would be annoyed if the object.method syntax was included.

But Ada has always had Object.Operation syntax, once you realize that
Object can be

* a package
* a task
* a protected object

Not everything needs to be extensible, with compiler-hidden run-time
overload resolution. If you think otherwise, then perhaps you should be
using a "pure" OO language like SmallTalk.

-- 
Jeffrey Carter

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Fri, 12 Oct 2001 17:01:14 GMT, Jeffrey Carter
<jeffrey.carter@boeing.com> wrote:


>But Ada has always had Object.Operation syntax, once you realize that
>Object can be
>
>* a package
>* a task
>* a protected object

True, although only for the task and protected object - you can't
consider the package as an object because it isn't an instance of a
type.

Re: on package naming, should the word "_pkg" be part of it?

[Jeffrey Carter]

John McCabe wrote:
> 
> On Fri, 12 Oct 2001 17:01:14 GMT, Jeffrey Carter
> <jeffrey.carter@boeing.com> wrote:
> 
> >But Ada has always had Object.Operation syntax, once you realize that
> >Object can be
> >
> >* a package
> >* a task
> >* a protected object
> 
> True, although only for the task and protected object - you can't
> consider the package as an object because it isn't an instance of a
> type.

Of course I can consider a package as an object. Just watch ... see, I
just considered the package as an object.

I don't know if we're discussing the same thing here, given that Ada
defines an object as a variable or typed constant. With that definition,
a package cannot be an object, and I agree.

If on the other hand you're referring to "Object Oriented", object
orientedness is a design attribute. One-package-per-Object is a
perfectly reasonable way to implement such a design, so I disagree.

-- 
Jeffrey Carter

Re: on package naming, should the word "_pkg" be part of it?

[Pascal Obry]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:
> Of course I can consider a package as an object. Just watch ... see, I
> just considered the package as an object.

I followed this thread and I thought that I should contribute a bit...

I think that the main difference is that many languages do impose a certain
design based on class (Eiffer, Java...). But Ada here does not. Ada has many
building blocks and the programer is in charge to assemble them the best way
for the job to be done. I think that this is of course a nice thing but it
needs a bit more attention during the design.

I think the problem peoples have with OO in Ada is just that.

Just my 2 cents,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: on package naming, should the word

[Ted Dennison]

In article <3bca98d8.736428@news.demon.co.uk>, John McCabe says...
>
>True, although only for the task and protected object - you can't
>consider the package as an object because it isn't an instance of a
>type.

The way I was taught it, an "object" consists of a data type, together with the
operations on that type. Since a package is one means of encapsulating both
those things into one concept, it can indeed be considered an "object".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Robert*]

In article <%DHy7.30147$ev2.37198@www.newsranger.com>, Ted says...
>
 
>
>The way I was taught it, an "object" consists of a data type, together with the
>operations on that type. Since a package is one means of encapsulating both
>those things into one concept, it can indeed be considered an "object".
>
 
If you "think" of a package as an object, then what do you "think" of
when you think about the tagged record inside the package?

An object inside an object? 

What do you see when you think of an array of object? an array of packages?

All of this becuase Ada does not have a separate class construct that
shows where a class starts and where it ends clearly. If anything Ada00 can
fix, is this part of Ada.

Re: on package naming, should the word

[Ted Dennison]

In article <9qfi9q01ke@drn.newsguy.com>, Robert*@ says...
>
>If you "think" of a package as an object, then what do you "think" of
>when you think about the tagged record inside the package?

You are veering the discussion off of the topic it was on. I was talking about
the generic-package OO technique. You (probably) wouldn't use a tagged record
with that technique. We were doing this in Ada 83 a decade before Ada 95 with
its tagged types existed.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Jeffrey Carter]

"Robert*@" wrote:
> 
> In article <%DHy7.30147$ev2.37198@www.newsranger.com>, Ted says...
> >
> >The way I was taught it, an "object" consists of a data type, together with the
> >operations on that type. Since a package is one means of encapsulating both
> >those things into one concept, it can indeed be considered an "object".
> >
> 
> If you "think" of a package as an object, then what do you "think" of
> when you think about the tagged record inside the package?
> 
> An object inside an object?

Package-as-Object refers to a package with only subprograms visible,
with the data storage in the package body. This defines an ASM.

A package with a type declaration and operations on the type defines an
ADT.

> 
> What do you see when you think of an array of object? an array of packages?

An object is an ASM or an instance of an ADT. An array of objects must
be an array of instances of an ADT.

Part of the confusion stems from 2 meanings for "type". In Ada, "type"
is used for defining a set of values.

For at least 30 years, the term "type" has been defined in S/W
engineering to mean a set of values and the operations on those values,
preferably encapsulated together, with a nice interface and unnecessary
information hidden. The result is an ADT.

In many languages, the Class construct provides all this. In many of
those languages, the Class construct is the only construct to provide
encapsulation and information hiding.

In Ada, there is separation of concerns. Type declarations define sets
of values, subprograms define operations on sets of values, and packages
provide encapsulation, information hiding, and modularity. Thus, the
combination of a type declaration and subprograms operating on that
type, encapsulated in a package, defines an ADT. Since not everything
that needs encapsulation and information hiding defines an ADT, and not
all types need to be ADTs, the separation of concerns allows all these
kinds of things.

If an ADT definition contains a tagged type, then the ADT is extensible
and calls to its operations may be dispatching. When extensibility is
not required, the ADT may contain a non-tagged type.

Those who do not recognize the special status packages have in Ada will
find themselves fighting the language. In a similar manner, those who do
not recognize the special status classes have in C++ will not understand
the idiom of using a class to obtain encapsulation and information
hiding, even though an ADT is not needed.

-- 
Jeffrey Carter

Re: on package naming, should the word

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]


"Robert*@" <Robert_member@newsguy.com> a �crit dans le message news: 9qfi9q01ke@drn.newsguy.com...
> If you "think" of a package as an object, then what do you "think" of
> when you think about the tagged record inside the package?
>
> An object inside an object?
>
> What do you see when you think of an array of object? an array of packages?
>
> All of this becuase Ada does not have a separate class construct that
> shows where a class starts and where it ends clearly. If anything Ada00 can
> fix, is this part of Ada.
>
Since this keeps going on, I can't resist to provide my own Euros 0.02 worth...

As noted before, Ada has no predefined paradigms. It has building blocks. All "classical" paradigms are design patterns. Here are
some useful ones:

A "class" in the usual sense: a tagged type inside a package, with primitive operations and nothing else.
Two "friends" classes: two tagged types in a package (with primitive operations).
Private inheritance: a tagged private type, whose full type is indirectly derived, i.e. (just a scheme, not something compilable):
   package My_Class is
      type Instance is new Other_Class.Instance with private;
      -- primitive operations
   private
      type Intermediate is new Other_Class with....
      type Instance is new Intermediate with....
   end My_Class;

All these constructs (and more) require special syntax in other languages. In Ada, you can build them by assembling the building
blocks in various ways. You can even build new paradigms that could not be possible in other languages without language changes.

The difference between Ada and other languages is the difference between Lego blocks and Playmobil. Playmobil pieces are very finely
defined for one purpose, but only one. It is almost impossible to mix a Playmobil piece from a box with pieces from other boxes. On
the other hand, Lego blocks are totally interoperative. It is the same round piece that serves as an umbrella in the Lego village,
as an parabollic antenna in the Space Lego, and as a shield in the Middle-Age Lego. The pieces in themselves have no predefined
usage: it is the way you assemble them with other pieces that gives their meaning.

I would advocate that Lego favours much more creativity than Playmobil...

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

Re: on package naming, should the word

[John McCabe]

On Mon, 15 Oct 2001 20:26:35 GMT, Ted Dennison<dennison@telepath.com>
wrote:

>The way I was taught it, an "object" consists of a data type, together with the
>operations on that type. Since a package is one means of encapsulating both
>those things into one concept, it can indeed be considered an "object".

For a generic package, sure, but not a non-generic package. An object
is a specific instance of a more generalised entity. The more
generalised entity may be a user-defined or language-defined type, a
Class (e.g in C++ and Java) etc.

A (non-generic) package is simply a means of encapsulating something
that can be instantiated as an object - e.g. a tagged type.
Conceptually Java's package mechanism is similar to Ada's in this
respect (although a bit naff) because Java Packages encapsulate
Classes and Interfaces that can be instantiated (or implemented) in
user programs - an Ada package encapsulated e.g. tagged types that can
be instantiated by user programs.

Re: on package naming, should the word

[Jeffrey Carter]

John McCabe wrote:
> 
> On Mon, 15 Oct 2001 20:26:35 GMT, Ted Dennison<dennison@telepath.com>
> wrote:
> 
> >The way I was taught it, an "object" consists of a data type, together with the
> >operations on that type. Since a package is one means of encapsulating both
> >those things into one concept, it can indeed be considered an "object".
> 
> For a generic package, sure, but not a non-generic package. An object
> is a specific instance of a more generalised entity. The more
> generalised entity may be a user-defined or language-defined type, a
> Class (e.g in C++ and Java) etc.
> 
> A (non-generic) package is simply a means of encapsulating something
> that can be instantiated as an object - e.g. a tagged type.

Bollards! A non-generic package may be the only instance of a design
concept:

package Stupid_Queue is
   procedure Put (Item : in Integer);

   function Get return Integer;
end Stupid_Queue;

[Properly documenting this specification and implementing the body are
left as exercises for the reader.]

This is an instance of the more general concept of a queue of integers.
This is a contrived example that should never be found in practice, but
application-specific cases in which neither extensibility nor multiple
instances are required are certainly not impossible to conceive.

-- 
Jeffrey Carter

Re: on package naming, should the word

[John McCabe]

On Tue, 16 Oct 2001 16:57:49 GMT, Jeffrey Carter
<jeffrey.carter@boeing.com> wrote:


>> A (non-generic) package is simply a means of encapsulating something
>> that can be instantiated as an object - e.g. a tagged type.

>Bollards! A non-generic package may be the only instance of a design
>concept:

Good point - I can accept that and, in this case the package could be
considered as an object. I'm convinced, especially as this is a means
of implementing the Singleton pattern (which I looked at in some depth
a while ago).

Re: on package naming, should the word "_pkg" be part of it?

[M. A. Alves]

The Object.Method syntax can be implemented with preprocessing (please
correct me if I am wrong on this).

The "class construct" depends on the definition of class. If class =
package (*) then it is trivial (preprocessing also suffices). But I
suspect the classists have another idea (of what a class is), requiring
semantic access.

However the term "class" in Ada is already occupied (as you know it
denotes a derivation class i.e. all types derived from some root), so it
would be a bit akward to have another "class" semantically.

(*) This rough equivalence used to be taught in a softw. eng. course at
FCTUNL.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: on package naming, should the word

[Ted Dennison]

In article <mailman.1002817756.16222.comp.lang.ada@ada.eu.org>, M. A. Alves
says...
>
>The Object.Method syntax can be implemented with preprocessing (please
>correct me if I am wrong on this).

If you are dying for it, you can also implement it with generic packages. You
don't get runtime polymorphism this way, but on the plus side this technique
works with Ada 83 too.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[M. A. Alves]

> >The Object.Method syntax can be implemented with preprocessing (please
> >correct me if I am wrong on this). (I)
>
> If you are dying for it, you can also implement it with generic packages. You
> don't get runtime polymorphism this way, but on the plus side this technique
> works with Ada 83 too. (TED)

I am not dying for it myself, personally I prefer Method(Object), but I
simpathise with the proposal of making Object.Method available if it is
easy to do so.

Now, you mean Object = Package (instantiation).  That is already an
available OO idiom in Ada, but is not the required thing: as you say
yourself, you dont have runtime polymorphism; it is a weaker OO idiom.

The requirement is very clear: Object = object as per ARM.

I propose to do it with preprocessing in order to keep the language
definition unchanged w.r.t. this.

Cheers,

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: on package naming, should the word

[Richard Riehle]

"M. A. Alves" wrote:

> > >The Object.Method syntax can be implemented with preprocessing (please
> > >correct me if I am wrong on this). (I)

I knew at least one developer group that wrote many of its packages
without generic formal parameters this way.

                  generic                  -- Note the absence of formal parameters

                  package Q is
                     type T is ...
                     procedure P1 ...
                     procedure P2 ...
                     function F1 ... return ...
                 private
                      ...
                 end Q;

Then, the package had to be instantiated before it could be used.

               package D is new Q;

so each exported entity could be invoked using the distinguished receiver
model.   Their rationale was slightly different from what it being discussed
here.   In their case, they wanted to be able to control elaboration at an exactly
designated place in their code.   As pointed out elsewhere, this does have a
downside when considered in terms of dynamic binding.

Richard Riehle

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On Thu, 11 Oct 2001 18:37:59 +0000 (GMT), M. A. Alves wrote:
> The Object.Method syntax can be implemented with preprocessing (please
> correct me if I am wrong on this).

Wouldn't you lose some of the dispatching capabilities of Ada then?

Preben

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Thu, 11 Oct 2001 21:03:49 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:

>On Thu, 11 Oct 2001 18:37:59 +0000 (GMT), M. A. Alves wrote:
>> The Object.Method syntax can be implemented with preprocessing (please
>> correct me if I am wrong on this).
>
>Wouldn't you lose some of the dispatching capabilities of Ada then?

No reason why you should because you would be writing your own
preprocessor :-)

All you'd do (using a rough example of my suggestion earlier) would be
to convert:

class XXX is
   procedure DoSomething;
   procedure AClassOperation is classwide;
end XXX;

class YYY extends XXX is
   procedure DoSomething;
   Item_1 : Integer;
   ClassItem : Integer is classwide; -- Use classwide, not static!!!
end YYY;

into:

package XXXs is
   type XXX is abstract tagged null record;
   procedure DoSomething (This : in XXX);
   procedure AClassOperation;
end XXXs;

package YYYs is
   type YYY is new XXX with
      record
         Item_1 : Integer;
      end record;
   ClassItem : Integer;
end YYYs;

You'd have to be concerned about context and use clauses though!

Re: on package naming, should the word "_pkg" be part of it?

[M. A. Alves]

> > > The Object.Method syntax can be implemented with preprocessing
> > > (please correct me if I am wrong on this).
> > Wouldn't you lose some of the dispatching capabilities of Ada then?

No.

> All you'd do (using a rough example of my suggestion earlier) would be
> to convert:
>
> class XXX is
>    procedure DoSomething;
>    procedure AClassOperation is classwide;
> end XXX;
>
> class YYY extends XXX is
>    procedure DoSomething;
>    Item_1 : Integer;
>    ClassItem : Integer is classwide; -- Use classwide, not static!!!
> end YYY;
>
> into:
>
> package XXXs is
>    type XXX is abstract tagged null record;
>    procedure DoSomething (This : in XXX);
>    procedure AClassOperation;
> end XXXs;
>
> package YYYs is
>    type YYY is new XXX with
>       record
>          Item_1 : Integer;
>       end record;
>    ClassItem : Integer;
> end YYYs;

Yes, looks like a sound equivalence model.  For preprocessing only
though; dont agree to put this in the language.

Cheers,

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On 11 Oct 2001 08:34:01 -0700, Robert* @ wrote:
> 
> Languages get changed all the time. If a language does not adopt it dies.
> 
> Ada itself changed. we had Ada83, then came Ada95 to add OO features becuase
> that what was needed to keep Ada moving along with the current needs of
> software.
> 
> C changed, C++ came from C to add OO to it.
> 
> Fortran changed. now we have fortran 90.
> 
> COBOL changed.
> 
> Java is being changed to add generics to it.
> 
> may be the word change is troubling, may the word improve is better.
> 
> The point is, if a langauge does not adopt and improve with time, it will be
> left behind, and people will go use (what is seen as) more modern languages.

You are arguing; Ada has to change syntax as the languages X, Y and Z
have done this. How can you claim that C -> C++ was a syntax change? How
can you say that the change in any of the language above (with the
exeption of COBOL which I do not know) was motivated by a wish for
changing the syntax? :-) As fas as I know the changes were because new
methology was added, like OO.

I have to use Fortran 77 from time to time, and even as painful as its
syntax is I do not want a Fortran 78 that has only changed some syntax
aspects and thus break compability with all the available Fortran 77
source the project has.

Ada 95 on the other hand has a beautiful and clear syntax which I like
very much. I like to read letters and numbers to a bunch of dots,
brackets, arrows etc... I understand that people from the C(++) and
likes doesn't at first like the somewhat more verbose syntax. I remember
I was not liking the Ada syntax at first as I thought it was like
Pascals (we had to use pascal at the university and I didn't like it as
it was a strict language where you still could crash the computer due to
the use of pointers.), but as I looked more at Ada source code I noticed
that it was so easy to read it and I found soon to prefer it to the
C(++) syntax.

Syntax like ++ -- *= etc is junk which only leads to error in your
programs.

If writing:

   Counter := Counter + 1;

is too long to write then simply make a macro in you editor so that you
can write: Counter++; and it automatically expands it into the line
above, or write a preprocessor that can translate your code.

Doing stuff like: if (++Counter == Max) { ... is IMHO pure stupidity if
you ever want to be able to read your source code.

As for the .method notation there is a very good example in the link I
posted earlier.

So I hope Ada won't change syntax and at least not to one that is worse
than it currently has.

Preben Randhol

Re: on package naming, should the word "_pkg" be part of it?

[David Starner]

On Thu, 11 Oct 2001 21:01:36 +0000 (UTC), Preben Randhol <randhol+abuse@pvv.org> wrote:
> I have to use Fortran 77 from time to time, and even as painful as its
> syntax is I do not want a Fortran 78 that has only changed some syntax
> aspects and thus break compability with all the available Fortran 77
> source the project has.

You do know that Fortran 90 has two syntaxs; the old Fortran 77-style
fixed form, and a new free form without the column restrictions and
stuff? No evolutionary step there; a whole new format, with a binary
choice between the two.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On 12 Oct 2001 02:04:14 GMT, David Starner wrote:
> On Thu, 11 Oct 2001 21:01:36 +0000 (UTC), Preben Randhol <randhol+abuse@pvv.org> wrote:
>> I have to use Fortran 77 from time to time, and even as painful as its
>> syntax is I do not want a Fortran 78 that has only changed some syntax
>> aspects and thus break compability with all the available Fortran 77
>> source the project has.
> 
> You do know that Fortran 90 has two syntaxs; the old Fortran 77-style
> fixed form, and a new free form without the column restrictions and
> stuff? No evolutionary step there; a whole new format, with a binary
> choice between the two.

Huh? There is a bigger difference than that. I have to use a F90
compilor as I have no F77 compilor, but I still have to code in F77 not
F90. 

   http://www-unix.mcs.anl.gov/dbpp/text/node84.html

Preben

Re: on package naming, should the word "_pkg" be part of it?

[David Starner]

On Fri, 12 Oct 2001 09:02:55 +0000 (UTC), Preben Randhol <randhol+abuse@pvv.org> wrote: 
> Huh? There is a bigger difference than that. 

Yes, but the overall format is a major synatax change. That's all I was
trying to say.

> I have to use a F90
> compilor as I have no F77 compilor, but I still have to code in F77 not
> F90. 

Why don't you use G77?

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On 12 Oct 2001 19:15:43 GMT, David Starner wrote:
> 
> Why don't you use G77?

Because of the target platform.

Preben

Re: on package naming, should the word "_pkg" be part of it?

[Brian Rogoff]

On Thu, 11 Oct 2001, Preben Randhol wrote:
> Ada 95 on the other hand has a beautiful and clear syntax which I like
> very much.

Me too.

> I like to read letters and numbers to a bunch of dots,
> brackets, arrows etc... I understand that people from the C(++) and
> likes doesn't at first like the somewhat more verbose syntax. I remember
> I was not liking the Ada syntax at first as I thought it was like
> Pascals (we had to use pascal at the university and I didn't like it as
> it was a strict language where you still could crash the computer due to
> the use of pointers.), but as I looked more at Ada source code I noticed
> that it was so easy to read it and I found soon to prefer it to the
> C(++) syntax.
>
> Syntax like ++ -- *= etc is junk which only leads to error in your
> programs.

No, that's not the problem at all. Adding syntax like +:= in Ada (influenced
by Icon not C here :) would not compromise readability or lead to errors. I
don't know why you think it would.

> If writing:
>
>    Counter := Counter + 1;
>
> is too long to write then simply make a macro in you editor so that you
> can write: Counter++;

Yuck! What's wrong with Increment or even Incr, written in straight Ada?
You can even overload it to handle non-unit increment/decrement, and make
a generic so it works over discrete types. I happpen to think +:= reads a
little better, but really *very* little.

> As for the .method notation there is a very good example in the link I
> posted earlier.

CLOS and Dylan also uses function notation, though clearly they are far
more powerful than Ada in that they have multiple dispatch.

-- Brian

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On Fri, 12 Oct 2001 02:29:44 GMT, Brian Rogoff wrote:
>> Syntax like ++ -- *= etc is junk which only leads to error in your
>> programs.
> 
> No, that's not the problem at all. Adding syntax like +:= in Ada (influenced
> by Icon not C here :) would not compromise readability or lead to errors. I
> don't know why you think it would.

Because reading:

   Counter +:= 1;
   Product *:= 5;

is less clear than

   Counter := Counter + 1;
   Product := Product * 5;

If you even use a decent editor (read Vim ;-) ) then you don't even have
to type the Counter or Product variable the second time fully
(completion shortcut)

> You can even overload it to handle non-unit increment/decrement, and make
> a generic so it works over discrete types. I happpen to think +:= reads a
> little better, but really *very* little.

Why make things more complex when there is no need for it :-)

Preben

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Fri, 12 Oct 2001 08:45:21 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:


>Because reading:
>
>   Counter +:= 1;
>   Product *:= 5;

+:= 1 is probably a bad example because you'd expect to be provided
with an increment operator if you started going down that road
however, apart from the amount of typing involved, the advantage of
the pre- and post-increment operators were that it made it easier for
compiler writers to generate efficient code - i.e. it was *extremely*
obvious that you could convert the statement directly into the
underlying machines increment/decrement instruction (if it existed)
rather than having to go on and parse the number you're adding, the do
something different if the value was 1.

Re: on package naming, should the word

[Ted Dennison]

In article <slrn9sdink.b2.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
Randhol says...
>
>Because reading:
>
>   Counter +:= 1;
>   Product *:= 5;
>
>is less clear than
>
>   Counter := Counter + 1;
>   Product := Product * 5;
>
>If you even use a decent editor (read Vim ;-) ) then you don't even have
>to type the Counter or Product variable the second time fully
>(completion shortcut)

Hmmm. How about a minor mode for Emacs (c-junkie-mode) that automaticly
transforms the mathematical assignments, square-bracket array designators, comma
and question mark operators, squirly braces, and whatever else C addicts feel
*have* to be in a language lest they get the jitters, into proper Ada? It could
even do it on save, and transform it back on load for them. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word "_pkg" be part of it?

[David Starner]

On Fri, 12 Oct 2001 08:45:21, Preben Randhol <randhol+abuse@pvv.org> wrote:
> Because reading:
> 
>    Counter +:= 1;
>    Product *:= 5;
> 
> is less clear than
> 
>    Counter := Counter + 1;
>    Product := Product * 5;

How about:

Counter (SCSU_Element (Active_Windows (Current_Item - Previous_Item)) 
         + 16#80#) +:= 1;

versus

Counter (SCSU_Element (Active_Windows (Current_Item - Previous_Item)) 
         + 16#80#) := 
	Counter (SCSU_Element (Active_Windows (Current_Item - Previous_Item)) 
        + 16#80#) + 1;

? Clarity is one of the real arguments for this syntax, so that you
don't make a mistake retyping the element on the left in these
situations, and so it's easy to tell on reading that the left part is the
same as the right part.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: on package naming, should the word "_pkg" be part of it?

[Vector..]

In article <9q7fr3$7hu2@news.cis.okstate.edu>, David says...
>
 

>? Clarity is one of the real arguments for this syntax, so that you
>don't make a mistake retyping the element on the left in these
>situations, and so it's easy to tell on reading that the left part is the
>same as the right part.
 
exactly. 

I do find that reading  'i++' is clearer than 'i := i +1', specially when
"i" is a complicated expression.

Ada programmers think that more words makes things clearer, but too
much words makes things less clear actually.  

A balance is good. Not too terse, and not too verbose.

Mathematics had its most advances when symbols were discovered. (these days
we seem to have run out of new symbols for mathematicans to use :)

Re: on package naming, should the word "_pkg" be part of it?

[Brian Rogoff]

On 12 Oct 2001, it was written:
> In article <9q7fr3$7hu2@news.cis.okstate.edu>, David says...
> >? Clarity is one of the real arguments for this syntax, so that you
> >don't make a mistake retyping the element on the left in these
> >situations, and so it's easy to tell on reading that the left part is the
> >same as the right part.
>
> exactly.
>
> I do find that reading  'i++' is clearer than 'i := i +1', specially when
> "i" is a complicated expression.

I agree, but as I said before if this really, really bothers you, you can
define an Increment (or Incr :) procedure and similar Decrement, and
Multiply procedures to ameliorate this quite a bit.

No, it's not quite as nice as a shorthand syntax, but in combination with
a few other Ada features (overloading, renames, generics) it isn't bad.
If you haven't done so, you may want to define a generic package over
dicrete types that does what you want.

> Ada programmers think that more words makes things clearer, but too
> much words makes things less clear actually.

I agree here too, but I think Ada is closer to being "right" than C++,
which doesn't even do a great job representing the "terser is mostly
better" philosophy.

However, its really too late to change Ada (or C++ for that matter) so
if you're really interested in using Ada (if not, you're wasting your time
in this ng) its wise to learn how to do things in Ada.

-- Brian

Re: on package naming, should the word "_pkg" be part of it?

[Mark Biggar]

David Starner wrote:
> 
> On Fri, 12 Oct 2001 08:45:21, Preben Randhol <randhol+abuse@pvv.org> wrote:
> > Because reading:
> >
> >    Counter +:= 1;
> >    Product *:= 5;
> >
> > is less clear than
> >
> >    Counter := Counter + 1;
> >    Product := Product * 5;
> 
> How about:
> 
> Counter (SCSU_Element (Active_Windows (Current_Item - Previous_Item))
>          + 16#80#) +:= 1;
> 
> versus
> 
> Counter (SCSU_Element (Active_Windows (Current_Item - Previous_Item))
>          + 16#80#) :=
>         Counter (SCSU_Element (Active_Windows (Current_Item - Previous_Item))
>         + 16#80#) + 1;
> 
> ? Clarity is one of the real arguments for this syntax, so that you
> don't make a mistake retyping the element on the left in these
> situations, and so it's easy to tell on reading that the left part is the
> same as the right part.

declare
	ctr: counter_type renames
		Counter (SCSU_Element (Active_Windows 
			(Current_Item - Previous_Item)) + 16#80#);
begin
	ctr := ctr + 1;
end;

--
Mark Biggar
mark.a.biggar@home.com

Re: on package naming, should the word "_pkg" be part of it?

[John McCabe]

On Thu, 11 Oct 2001 21:01:36 +0000 (UTC), Preben Randhol
<randhol+abuse@pvv.org> wrote:

>As fas as I know the changes were because new
>methology was added, like OO.

Like was added with Ada 95, except none of the syntax changed, just a
few more keywords were added (tagged, class etc).

Apart from the object.method syntax, and probably a 'class' construct,
I wouldn't change much in Ada. It is certainly a clear and generally
understandable syntax (although I've known many people have difficulty
with the concept of 'access all my_type' and just 'access my_type').

Re: on package naming, should the word "_pkg" be part of it?

[Preben Randhol]

On 11 Oct 2001 05:07:27 -0700, Robert* @ wrote:
> 
> We can argue this for many years to come. Technical discussions on this mean 
> very little any more. At the end of the day, if you want more people to 
> use Ada, Ada must implements the class construct and allow programmers 
> to use object.method(). 

And I guess one must also change: := to = and = to == as well as add
syntactic junk like ++ -- *= etc... ?

Preben

Re: on package naming, should the word

[Ted Dennison]

In article <9q421v0bbg@drn.newsguy.com>, Robert*@ says...
>We can argue this for many years to come. Technical discussions on this mean 
>very little any more. At the end of the day, if you want more people to 
>use Ada, Ada must implements the class construct and allow programmers 
>to use object.method(). 

If you take that stance, we *will* argue this for many years to come. The only
indisputable problem with Method(Object) is that it isn't what C++ does. If you
want the language to do what C++ does, use C++.

I'll repeat Ted mantra #5: "different" /= "bad"

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Robert*]

In article <mlhx7.24432$ev2.32999@www.newsranger.com>, Ted says...
>
 

>If you take that stance, we *will* argue this for many years to come. The only
>indisputable problem with Method(Object) is that it isn't what C++ does. 


that is where you are wrong. 

the class construct is the basic construct in OO as commonly used. Ada 
does not have it. It is that simple. Ada does do OO, but not using the 
common OO notation.

You can argue for years which is the better notation, but the fact remains
that the Java/C++ notation for OO is the common and the popular one and the
one most programmer are used to,  not the Ada notation.

of course, Ada does not have to change, and Ada will remain not popular. 

If this is Ok with the Ada community, it is Ok with me. I have nothing at
all to gain by Ada becomming more popular or less popular, I am only
giving you my opinion of what will make Ada more popular and make it more
used. 

 

Re: on package naming, should the word

[Ted Dennison]

In article <9q4d850163k@drn.newsguy.com>, Robert*@ says...
>
>the class construct is the basic construct in OO as commonly used. Ada 
>does not have it. It is that simple. Ada does do OO, but not using the 

So now you are saying something isn't a "class" in your book if you can't use
"distinguished receiver" notation on its method calls? Come on, that's just
silly. I could just as easily argue that something that *does* use distinguished
receiver notation doesn't have "classes" in my book, because there's no way to
dispatch on multiple objects, like there is in Ada.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: on package naming, should the word

[Larry Kilgallen]

In article <9q4d850163k@drn.newsguy.com>, Robert*@ <Robert_member@newsguy.com> writes:

> If this is Ok with the Ada community, it is Ok with me. I have nothing at
> all to gain by Ada becomming more popular or less popular, I am only
> giving you my opinion of what will make Ada more popular and make it more
> used. 

If Ada is more widely used by people who are not willing to understand
the difference between different languages, I don't see any benefit.

My end goal is not Ada; it is better software.

Re: on package naming, should the word

[Marin David Condic]

I would seriously doubt that Ada's relative lack of popularity is due to its
lack of some particular OO syntax notation. I would also doubt that a change
of its syntax would suddenly result in lots of OO programmers coming into
the fold. Lots more has to be going into "popularity" than just the syntax.

Consider that any syntax change - no matter how slight - can throw a monkey
wrench into truckloads of existing systems and cost existing users bundles
of money to fix. One doesn't do that on a whim. Just adding a new reserved
word puts every system into the "at risk" category. You can't expect to
change something as fundamental to existing ada as the Method (Object)
notation into Object.Method notation and not have that stir up the pot to
the point where existing users are hurt severely. If a syntax change is in
order, it would only likely happen if someone can show that the existing
syntax is seriously "broke".

Since a solution does exist - just not the same one as is seen in C++/Java -
and that solution is not humungously painful, it doesn't seem warranted to
change the syntax. However, if you could come up with a petition from a
really large number of Java users who promise under penalty of law to switch
languages if only Ada will give them Object.Method, you might have a case
:-)

In the mean time, I'd suggest building a preprocessor that lets you write it
whatever way you like. I believe GNAT supports the ability to invoke a
preprocessor of the user's choice. Put it out where all the Java/C++ users
can see it and see if any jump on the bandwagon. That's an easy way to
experiment with Ada syntax & see how popular the changes may be.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert*@" <Robert_member@newsguy.com> wrote in message
news:9q4d850163k@drn.newsguy.com...
>
> that is where you are wrong.
>
> the class construct is the basic construct in OO as commonly used. Ada
> does not have it. It is that simple. Ada does do OO, but not using the
> common OO notation.
>
> You can argue for years which is the better notation, but the fact remains
> that the Java/C++ notation for OO is the common and the popular one and
the
> one most programmer are used to,  not the Ada notation.
>
> of course, Ada does not have to change, and Ada will remain not popular.
>
> If this is Ok with the Ada community, it is Ok with me. I have nothing at
> all to gain by Ada becomming more popular or less popular, I am only
> giving you my opinion of what will make Ada more popular and make it more
> used.
>
>
>

Re: on package naming, should the word

[Simon Wright]

Robert*@ <Robert_member@newsguy.com> writes:

> the class construct is the basic construct in OO as commonly
> used. Ada does not have it. It is that simple. Ada does do OO, but
> not using the common OO notation.
> 
> You can argue for years which is the better notation, but the fact
> remains that the Java/C++ notation for OO is the common and the
> popular one and the one most programmer are used to, not the Ada
> notation.

I have a reference from someone I trust to an extent (Martin Fowler)
that Smalltalk is highly favoured among the business community. The
statement was a few years back (97?). So where would _that_ leave
C++/Java style?

Re: on package naming, should the word

[John McCabe]

On 11 Oct 2001 21:16:03 +0100, Simon Wright <simon@pushface.org>
wrote:

>Robert*@ <Robert_member@newsguy.com> writes:
>
>> the class construct is the basic construct in OO as commonly
>> used. Ada does not have it. It is that simple. Ada does do OO, but
>> not using the common OO notation.
>> 
>> You can argue for years which is the better notation, but the fact
>> remains that the Java/C++ notation for OO is the common and the
>> popular one and the one most programmer are used to, not the Ada
>> notation.
>
>I have a reference from someone I trust to an extent (Martin Fowler)
>that Smalltalk is highly favoured among the business community. The
>statement was a few years back (97?). So where would _that_ leave
>C++/Java style?

So what does Smalltalk look like? I believe we have a mutual
acquaintance who used Smalltalk at one point, but I can't remember how
class methods were called.

Re: on package naming, should the word

[Darren New]

> So what does Smalltalk look like? I believe we have a mutual
> acquaintance who used Smalltalk at one point, but I can't remember how
> class methods were called.

Basically three different syntaxes:

Unary operators:
target_expr no_argument_method_identifier
    25 cosine
    iterator next
    array new
    my_list sort

Binary operators:
target_variable + argument
    (where "+" is any string of non-alphanumerics)
    2 + 5
    value $%^ expression
    cursor -> new_position

N-ary operators
target keyword1: arg1 keyword2: arg2 keywordN: argN
    my_array at: 27 put: value
    window drawLineFromX: 3 Y: 7 toX: 13 Y: 27

No dots in there at all.
    
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
                   Who is this Dr. Ibid anyway, 
                  and how does he know so much?

Re: on package naming, should the word

[Jacob Sparre Andersen]

Robert:

> You can argue for years which is the better notation, but the fact remains
> that the Java/C++ notation for OO is the common and the popular one and the
> one most programmer are used to,  not the Ada notation.

Nobody claims that the C++ notation is less popular.

The object prefix notation has a very serious limitation,
which would actually break quite a few of my programs. Using
the object prefix notation, it is not possible to dispatch
on the function result type.

Jacob

PS: Millions of lemmings can't be wrong, ...
-- 
http://www.ldraw.org/download/start/linux/
                           Kom i gang med LEGO CAD p� Linux.

Re: on package naming, should the word

[Robert*]

In article <3BC9F6CC.E41BE18A@nbi.dk>, Jacob says...
>
 
>The object prefix notation has a very serious limitation,
>which would actually break quite a few of my programs. Using
>the object prefix notation, it is not possible to dispatch
>on the function result type.
>
 
A simple example of what you mean? 

Re: on package naming, should the word

[Lutz Donnerhacke]

* Robert*@ wrote:
>In article <3BC9F6CC.E41BE18A@nbi.dk>, Jacob says...
>>The object prefix notation has a very serious limitation,
>>which would actually break quite a few of my programs. Using
>>the object prefix notation, it is not possible to dispatch
>>on the function result type.
>
>A simple example of what you mean? 

  type Error is tagged abstract private;
  procedure Alarm (e : Error) is abstract;
  function Current_Error returns Error'Class;
...
  Alarm (Current_Error);
  

Re: on package naming, should the word

[Florian Weimer]

lutz@iks-jena.de (Lutz Donnerhacke) writes:

> * Robert*@ wrote:
> >In article <3BC9F6CC.E41BE18A@nbi.dk>, Jacob says...
>>>The object prefix notation has a very serious limitation,
>>>which would actually break quite a few of my programs. Using
>>>the object prefix notation, it is not possible to dispatch
>>>on the function result type.
>>
>>A simple example of what you mean? 
>
>   type Error is tagged abstract private;
>   procedure Alarm (e : Error) is abstract;
>   function Current_Error returns Error'Class;
> ...
>   Alarm (Current_Error);

Python translation, in prefix notation:

    class Error:
        def Alarm(self):
            pass
    
    def Current_Error():
        ...
        return <something>
    
    Current_Error().Alarm()

In your example, Current_Error is clearly non-dispatching, so this is
not an example for dispatching on the function result type.

By the way, C++ does indeed offer static dispatching on the function
return type, but the last time I tried it, it involved a considerable
syntactic overhead.

Re: on package naming, should the word "_pkg" be part of it?

[Mats Karlssohn]

"Robert*@" wrote:
%<
> As was said many times, object.method() vs. method(object); is only syntax, but
> it is an important syntax difference.
> 
> We can argue this for many years to come. Technical discussions on this mean
> very little any more. At the end of the day, if you want more people to
> use Ada, Ada must implements the class construct and allow programmers
> to use object.method().

I now feel that I must jump into this arguement (spl ?)

Isn't it so, that IF programmers can't adapt to minor syntactical
differences (such as the object.method() vs. method(object) issue or the
BEGIN/END vs. {} issue) THEN they are probably pretty bad programmers
anyway (who probably would have benefited from Ada;s belt and suspenders
approach) ?

Sorry about the long sentence with lots of ()!

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: on package naming, should the word "_pkg" be part of it?

[Larry Kilgallen]

In article <3BCA8730.E660DB5E@mida.se>, Mats Karlssohn <mats@mida.se> writes:

> Isn't it so, that IF programmers can't adapt to minor syntactical
> differences (such as the object.method() vs. method(object) issue or the
> BEGIN/END vs. {} issue) THEN they are probably pretty bad programmers
> anyway (who probably would have benefited from Ada;s belt and suspenders
> approach) ?

The technical effect of Ada's fail-safe technical approach applies
to certain limited areas where defects are susceptible to mechanical
detection.  There is a larger effect on the mindset of Ada users,
who will use other capabilities of the language (e.g., use of
enumeration types rather than integers) to achieve safer programs.

The bad programmers who can't learn Ada syntax also can't learn
safe programming in general, so I would rather have them _not_
using Ada.

Re: on package naming, should the word "_pkg" be part of it?

[Robert A Duff]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> Even this is incorrect. Current_Vehicle is not a car, it is a collection
> of information about a car:
> 
> Current_Vehicle : Car_Info;

This is to make sure that the person reading the code doesn't mistakenly
assume that the computer's memory chips actually contain cars?  ;-)

Here's one of the few types I can think of whose objects don't contain
information:

    type Color is (Red);

(so of course Color'Size should be 0).

- Bob

Re: on package naming, should the word "_pkg" be part of it?

[MM]

In article <9pif1o01btl@drn.newsguy.com>, mike@nospam says...
>
>i've seen some code where they write
>
>package foo_pkg is...
>
>
>i.e. the name of the package contains "pkg" or "package" in the name itself.
>
>this seems redundent to me, but may be not. what do folks think? 
>

with  foo.boo;

Now, boo need not be a package. it could be a subprogram, since subprograms
can be decalred as children of packages.

Probably not a common thing to do, but possible.