OOD in Ada?

OOD in Ada?

[David Crocker]

I know that Ada95 tries to support O-O development, but from my perspective
as an OO developer but Ada novice, it appears to me that any attempt to
implement a large OO design in Ada will run into the following problems:

1. The infamous "withing" problem (i.e. it is not possible to declare 2
classes A and B, each in its own package, such that A has a method taking a
paremeter of type "access B", and B has a method with a parameter of type
"access A"); and

2. The lack of a "dot" notation (or anything similar) for calling a member
method, making the code hard to read and hard to determine where dynamic
binding may be taking place.

So: is there anyone on this list who does serious object-oriented
development in Ada and would like to comment?

--
David Crocker
Escher Technologies Ltd.
www.eschertech.com

Re: OOD in Ada?

[Pat Rogers]

"David Crocker" <dcrocker@eschertech.com> wrote in message
news:3d135676$0$8511$cc9e4d1f@news.dial.pipex.com...
> I know that Ada95 tries to support O-O development, but from my perspective

From my perspective it succeeds.

> as an OO developer but Ada novice, it appears to me that any attempt to
> implement a large OO design in Ada will run into the following problems:
>
> 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> classes A and B, each in its own package, such that A has a method taking a
> paremeter of type "access B", and B has a method with a parameter of type
> "access A"); and

I have not found that problem to be frequent.  Others will tell about how to
deal with it.

> 2. The lack of a "dot" notation (or anything similar) for calling a member
> method, making the code hard to read and hard to determine where dynamic
> binding may be taking place.

The distinguished receiver syntax (the "dot notation") in no way indicates
whether or not dynamic dispatching occurs.  In Eiffel and Java, for example, it
happens all the time, and for C++ you have to look at the function definition to
see whether or not it is marked virtual such that dynamic dispatch is even
possible.  Similarly, in CLOS you look for "generic" functions.

--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: OOD in Ada?

[Ed Falis]

On Fri, 21 Jun 2002 17:20:13 GMT
"Pat Rogers" <progers@classwide.com> wrote:

> "David Crocker" <dcrocker@eschertech.com> wrote in message

> > 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> > classes A and B, each in its own package, such that A has a method taking a
> > paremeter of type "access B", and B has a method with a parameter of type
> > "access A"); and
> 
> I have not found that problem to be frequent.  Others will tell about how to
> deal with it.

There should be a writeup on John Volan's solution to this at www.adapower.com


> The distinguished receiver syntax (the "dot notation") in no way indicates
> whether or not dynamic dispatching occurs.  In Eiffel and Java, for example, it
> happens all the time, and for C++ you have to look at the function definition to
> see whether or not it is marked virtual such that dynamic dispatch is even
> possible.  Similarly, in CLOS you look for "generic" functions.

Whereas with Ada, the controlling arguments must be declared class-wide for dispatching to occur.

- Ed

Re: OOD in Ada?

[Ted Dennison]

Pat Rogers wrote:
> "David Crocker" <dcrocker@eschertech.com> wrote in message
> news:3d135676$0$8511$cc9e4d1f@news.dial.pipex.com...
>>as an OO developer but Ada novice, it appears to me that any attempt to
>>implement a large OO design in Ada will run into the following problems:
>>
>>1. The infamous "withing" problem (i.e. it is not possible to declare 2
>>classes A and B, each in its own package, such that A has a method taking a
>>paremeter of type "access B", and B has a method with a parameter of type
>>"access A"); and
> 
> 
> I have not found that problem to be frequent.  Others will tell about how to
> deal with it.

Since you can't do it, it will eventally become second nature to design 
in such a way that it doesn't happen. When it does, I generally consider 
this the language's little way of telling me that my code needs to be 
better structured.

Re: OOD in Ada?

[tmoran]

> >>1. The infamous "withing" problem (i.e. it is not possible to declare 2
> >>classes A and B, each in its own package, such that A has a method taking a
> >>paremeter of type "access B", and B has a method with a parameter of type
> >>"access A"); and
> ... telling me that my code needs to be better structured.
  Right.  A case can be made that if structure A needs to know about
B, and B needs to know about A, they probably should be in the same
package anyway (or at least children with a common ancestor they both
know).

Re: OOD in Ada?

[Ted Dennison]

tmoran@acm.org wrote in message news:<4peR8.134$F46.42900789@newssvr14.news.prodigy.com>...
> > >>1. The infamous "withing" problem (i.e. it is not possible to declare 2
> > >>classes A and B, each in its own package, such that A has a method taking a
> > >>paremeter of type "access B", and B has a method with a parameter of type
> > >>"access A"); and
> > ... telling me that my code needs to be better structured.
>   Right.  A case can be made that if structure A needs to know about
> B, and B needs to know about A, they probably should be in the same
> package anyway (or at least children with a common ancestor they both
> know).

9 times out of 10, I'd say it means that your control flow is a mess,
and one of the two needs to be promoted to "server" (and the other to
"client").

Note that the Grace list package's list and iterator types in the
reference implementation that I wrote fall into the 1 out of 10. So
I'm certianly not saying you should *never* do this. But you should
avoid it unless your two types really are inseperably interrelated.

Re: OOD in Ada?

[Stephen Leake]

Ted Dennison <dennison@telepath.com> writes:

> Pat Rogers wrote:
> > "David Crocker" <dcrocker@eschertech.com> wrote in message
> > news:3d135676$0$8511$cc9e4d1f@news.dial.pipex.com...
> >>as an OO developer but Ada novice, it appears to me that any attempt to
> >>implement a large OO design in Ada will run into the following problems:
> >>
> >>1. The infamous "withing" problem (i.e. it is not possible to declare 2
> >>classes A and B, each in its own package, such that A has a method taking a
> >>paremeter of type "access B", and B has a method with a parameter of type
> >>"access A"); and
> > I have not found that problem to be frequent.  Others will tell
> > about how to
> > deal with it.
> 
> Since you can't do it, it will eventally become second nature to
> design in such a way that it doesn't happen. 

Actually, you can do it in GNAT; it supports the "with type"
extension.

The only time I've used it is when importing Java code; that's why the
"with type" extension was added.

> When it does, I generally consider this the language's little way of
> telling me that my code needs to be better structured.

In general, I agree with this.

-- 
-- Stephe

Re: OOD in Ada?

[Marin David Condic]

"David Crocker" <dcrocker@eschertech.com> wrote in message
news:3d135676$0$8511$cc9e4d1f@news.dial.pipex.com...
> I know that Ada95 tries to support O-O development, but from my
perspective
> as an OO developer but Ada novice, it appears to me that any attempt to
> implement a large OO design in Ada will run into the following problems:
>
> 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> classes A and B, each in its own package, such that A has a method taking
a
> paremeter of type "access B", and B has a method with a parameter of type
> "access A"); and
>
I'm not sure that this is somehow or other essential to OO Programming.
Perhaps you just need to consider another way of doing it rather than try to
force an idiom from another language onto Ada. If you really need to do
that, you could probably do some version of deriving A and B from some lower
level type(s) that declares an access type to the underlying type(s)'Class -
then A and B can with the base types and get the access types they need.

A solution does exist - I just don't think I'm convinced that you really
need to do that and that failure to find a way means you can't do large OO
designs in Ada.

If you absolutely insist it is essential, try this:

package Base_Class is
    type Base_Type is tagged private ;
    type Base_Ptr is access all Base_Type'Class ;
    -- etc...
private
    type Base_Type is tagged null record ;
end Base_Class ;

package Base_Class.A is
    type A is new Base_Type with private ;
private
    type A is new Base_Type with record
        B_Ptr : Base_Ptr := null ;           -- Can point to any B without
"with"
    end record ;
end Base_Class.A ;

package Base_Class.B is
    type B is new Base_Type with private ;
private
    type B is new Base_Type with record
        A_Ptr : Base_Ptr := null ;
    end record;
end Base_Class.B ;


Iyou're familiar enough with Ada and OOP, you should be able to figure it
out from here... (And no, they don't both need to derive from the same base
type and they don't need to be child packages of the base class.)




> 2. The lack of a "dot" notation (or anything similar) for calling a member
> method, making the code hard to read and hard to determine where dynamic
> binding may be taking place.
>
This is just a syntax thing - one debated here a number of times in the
past. I don't find it essential or hard to read or anything like that. But
then, I'm used to looking at it from "Method (Object)" perspective rather
than "Object->Method" form. Whatever you are used to is going to make the
other way seem "Bad". If you decide to simply Get Over It and work with the
syntax that exists, you'll find it is no more confusing or difficult than
what you are used to.

It certainly won't stop you from implementing any large OO designs and if
you take the language as a whole, I think you'll find you gain lots of
benefits from using it that outweigh whatever downsides there may be to
having to learn & use something that is "Different". (Think of the benefits
you get from things like tasks, protected types, generics, etc. Isn't that
worth a little change in the syntax you are used to?)

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

Re: OOD in Ada?

[Jeffrey Carter]

David Crocker wrote:
> 
> I know that Ada95 tries to support O-O development, but from my perspective
> as an OO developer but Ada novice, it appears to me that any attempt to
> implement a large OO design in Ada will run into the following problems:

I've been implementing object-oriented designs in Ada since 1984. Object
orientation is a design feature, and has nothing to do with the use of
specific implementation features, nor does the use of such features mean
that the software is object oriented.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail

Re: OOD in Ada?

[Dr. Michael Paus]

David Crocker wrote:
> I know that Ada95 tries to support O-O development, but from my perspective
> as an OO developer but Ada novice, it appears to me that any attempt to
> implement a large OO design in Ada will run into the following problems:
> 
> 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> classes A and B, each in its own package, such that A has a method taking a
> paremeter of type "access B", and B has a method with a parameter of type
> "access A"); and

Yes, this is also considered a problem by other people.

This in an excerpt from the JGNAT user guide:

"A long-standing programming problem that is difficult to solve in Ada
is that of creating mutually dependent package specifications.  The
problem is that Ada package specifications aren't allowed to depend on
each other. There are various possibilities for working around this
restriction in specific cases, generally involving levels of
indirection and syntactically heavy programming idioms. However, these
workarounds are too cumbersome for practical use, [...]"

To overcome this problem the GNAT people even introduced a language extension
"with type". This feature is available in any recent GNAT implementation although
it does not seem to work (For the example I have used the compiler seems to go
into an endless loop). In order to activate it you have to use the -gnatX switch.
For a more extensive explanation of how it works see the JGNAT user manual.

> 2. The lack of a "dot" notation (or anything similar) for calling a member
> method, making the code hard to read and hard to determine where dynamic
> binding may be taking place.

This is indeed one of the more serious problems. Many people in this group
will argue that technically it does not make any difference whether you have
a "dot" notation or not and this is probably right. But from the point of
readability it is a big difference. This may of course be just a matter of
taste but in my daily work I have met a lot of people who have real difficulties
to understand what this OO stuff is all about. I think it is much easier to
explain and understand in a language like Java than it is in Ada.

> So: is there anyone on this list who does serious object-oriented
> development in Ada and would like to comment?

Well, this depends of course on how you define serious. What you mostly find
are projects where some OO features are used occasionally but not consistently.
Just using a tagged type here or there certainly does not qualify as "serious
object-oriented development". Personally I have not yet seen any Ada project
where a rigorous OO design and implemenation have been performed. In some
companies the use of any OO features of the language is even strictly forbidden.

Michael

Re: OOD in Ada?

[Pascal Obry]

"Dr. Michael Paus" <paus@ib-paus.com> writes:

> To overcome this problem the GNAT people even introduced a language extension
> "with type". This feature is available in any recent GNAT implementation
> although it does not seem to work (For the example I have used the compiler
> seems to go into an endless loop). In order to activate it you have to use
> the -gnatX switch. For a more extensive explanation of how it works see the
> JGNAT user manual.

Note that a similar issue has been raised and is worked-on see AI95-00217-01.
There has been many proposals, last I have heard the "with type" extension as
implemented in GNAT will not be the final solution.

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"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: OOD in Ada?

[Dr. Michael Paus]

Pascal Obry wrote:
> "Dr. Michael Paus" <paus@ib-paus.com> writes:
> 
> 
>>To overcome this problem the GNAT people even introduced a language extension
>>"with type". This feature is available in any recent GNAT implementation
>>although it does not seem to work (For the example I have used the compiler
>>seems to go into an endless loop). In order to activate it you have to use
>>the -gnatX switch. For a more extensive explanation of how it works see the
>>JGNAT user manual.
> 
> 
> Note that a similar issue has been raised and is worked-on see AI95-00217-01.
> There has been many proposals, last I have heard the "with type" extension as
> implemented in GNAT will not be the final solution.

I know about that but at least it is a feature which is available now and not
something you have to wait for until 2005 or whenever the next revision of Ada
is expected. By the way do you know whether this feature is still supposed to
work? I have not found a description of it outside the documentation of JGNAT
and when I tried it with GNAT 3.14p on Windows gnat1.exe seems to go into an
endless loop although it does seem to understand the feature. If you omit the
-gnatX switch it tells you that this is an Ada extension which you have to activate
explicitly.

Michael

Re: OOD in Ada? Correction

[Dr. Michael Paus]

Dr. Michael Paus wrote:
> Pascal Obry wrote:
> 
>> "Dr. Michael Paus" <paus@ib-paus.com> writes:
>>
>>
>>> To overcome this problem the GNAT people even introduced a language 
>>> extension
>>> "with type". This feature is available in any recent GNAT implementation
>>> although it does not seem to work (For the example I have used the 
>>> compiler
>>> seems to go into an endless loop). In order to activate it you have 
>>> to use
>>> the -gnatX switch. For a more extensive explanation of how it works 
>>> see the
>>> JGNAT user manual.
>>
>>
>>
>> Note that a similar issue has been raised and is worked-on see 
>> AI95-00217-01.
>> There has been many proposals, last I have heard the "with type" 
>> extension as
>> implemented in GNAT will not be the final solution.
> 
> 
> I know about that but at least it is a feature which is available now 
> and not
> something you have to wait for until 2005 or whenever the next revision 
> of Ada
> is expected. By the way do you know whether this feature is still 
> supposed to
> work? I have not found a description of it outside the documentation of 
> JGNAT
> and when I tried it with GNAT 3.14p on Windows gnat1.exe seems to go 
> into an
> endless loop although it does seem to understand the feature. If you 
> omit the
> -gnatX switch it tells you that this is an Ada extension which you have 
> to activate
> explicitly.
> 
> Michael
> 

I just got a mail from Robert Dewar concerning this issue saying:

"This feature was not approved by the ARG and will not be supported in future
(JGNAT itself is also no longer supported)"

There are now 4 different proposals on how to solve this problem (AI95-00217-01 .. -04).
So I am afraid we still have to wait a while until we get some working solution to
this problem.

Michael

Re: OOD in Ada? Correction

[Simon Wright]

"Dr. Michael Paus" <paus@ib-paus.com> writes:

> I just got a mail from Robert Dewar concerning this issue saying:
> 
> "This feature was not approved by the ARG and will not be supported
> in future (JGNAT itself is also no longer supported)"

Thank you for relaying that. I am _so_ glad I didn't commit to it!

Re: OOD in Ada? Correction

[Randy Brukardt]

Dr. Michael Paus wrote in message <3D147FAF.4090609@ib-paus.com>...

>I just got a mail from Robert Dewar concerning this issue saying:
>
>"This feature was not approved by the ARG and will not be supported in
future
>(JGNAT itself is also no longer supported)"
>
>There are now 4 different proposals on how to solve this problem
(AI95-00217-01 .. -04).
>So I am afraid we still have to wait a while until we get some working
solution to
>this problem.


Well, the good news is that while this was being debated here, the ARG
was meeting in Vienna. And we approved (to my great surprise)
AI-00217-04. So we have a "final" solution. How long it will be before
it starts showing up in compilers I don't know (several vendors have
worked on it, but whether it will be available in their compilers soon I
can't say).

(I haven't posted the final update to the AI yet.)

               Randy Brukardt
               ARG Editor

Re: OOD in Ada? Correction

[Preben Randhol]

Randy Brukardt <randy@rrsoftware.com> wrote on 29/06/2002 (02:03) :
> 
> Well, the good news is that while this was being debated here, the ARG
> was meeting in Vienna. And we approved (to my great surprise)
> AI-00217-04. So we have a "final" solution. How long it will be before
> it starts showing up in compilers I don't know (several vendors have
> worked on it, but whether it will be available in their compilers soon I
> can't say).

Sorry about my ignorance, but where can I see the AI-00217-04 proposal.
I seem to remember that these was available online ? Thanks in advance.


-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: OOD in Ada? Correction

[Mark Biggar]

Preben Randhol wrote:

> 
> Sorry about my ignorance, but where can I see the AI-00217-04 proposal.
> I seem to remember that these was available online ? Thanks in advance.

All the AI's can be found on www.ada-auth.org

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

Re: OOD in Ada? Correction

[Randy Brukardt]

Preben Randhol wrote in message ...
>Randy Brukardt <randy@rrsoftware.com> wrote on 29/06/2002 (02:03) :
>>
>> Well, the good news is that while this was being debated here, the
ARG
>> was meeting in Vienna. And we approved (to my great surprise)
>> AI-00217-04. So we have a "final" solution. How long it will be
before
>> it starts showing up in compilers I don't know (several vendors have
>> worked on it, but whether it will be available in their compilers
soon I
>> can't say).
>
>Sorry about my ignorance, but where can I see the AI-00217-04 proposal.
>I seem to remember that these was available online ? Thanks in advance.


AI-00217-04 is at:

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-30217.TXT

Keep in mind that there were some changes to this AI made at the
meeting, which I haven't applied yet to the text.

       Randy Brukardt
       ARG Editor

Re: OOD in Ada?

[steve_H]

"Dr. Michael Paus" <paus@ib-paus.com> wrote in message news:<3D1440FA.9030409@ib-paus.com>...
 
> 
> > 2. The lack of a "dot" notation (or anything similar) for calling a member
> > method, making the code hard to read and hard to determine where dynamic
> > binding may be taking place.
>
 
> This is indeed one of the more serious problems. 

I wish someone would create a new language just like Ada in everything, 
except the OO uses the normal 'class' construct as in Java and C++.

I think the main reason why Ada is not too popular is that its OO constructs
are not the norm, they do not look like what almost every programmer from
other languages is used to looking at.

It seems it should not be too hard for some language design expert to
design such a language. Or is there is anything out there that looks like
Ada, but with the 'class' for OO? Modula3 may be?

Re: OOD in Ada?

[Jim Rogers]

Steve_H wrote:

> I wish someone would create a new language just like Ada in everything, 
> except the OO uses the normal 'class' construct as in Java and C++.
> 
> I think the main reason why Ada is not too popular is that its OO constructs
> are not the norm, they do not look like what almost every programmer from
> other languages is used to looking at.
> 
> It seems it should not be too hard for some language design expert to
> design such a language. Or is there is anything out there that looks like
> Ada, but with the 'class' for OO? Modula3 may be?
> 


And we all know just how popular Modula3 is.

Using a "class" structure like C++ or Java will break everything
dealing with Ada packages. Breaking packages breaks all forms of
encapsulation and name space in Ada. Breaking these destroys
control of visibility of compilation units.

Yea. I guess we should make Ada more like C++ and Java.
That will fix everything.

Jim Rogers

Re: OOD in Ada?

[achrist]

Jim Rogers wrote:
> 
> Steve_H wrote:
> 
> > I wish someone would create a new language just like Ada in everything,
> > except the OO uses the normal 'class' construct as in Java and C++.
> >
> > I think the main reason why Ada is not too popular is that its OO constructs
> > are not the norm, they do not look like what almost every programmer from
> > other languages is used to looking at.
> >
> > It seems it should not be too hard for some language design expert to
> > design such a language. Or is there is anything out there that looks like
> > Ada, but with the 'class' for OO? Modula3 may be?
> >
> 
> And we all know just how popular Modula3 is.
> 

No, not M3. The OO features of M3 are just as different as those of
Ada, maybe moreso.  That must explain something.


Al

Re: OOD in Ada?

[Georg Bauhaus]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote:
: Yea. I guess we should make Ada more like C++ and Java.
: That will fix everything.

As a first step, try one of your programs with capitals
made lower case, and do not use a monospaced font.
Look at your Ada++ program then :-)

(Then, make keywords use a bold grotesque and identifiers
italic (antiqua), Symbols for symbols. Look again ... :-)

-- Georg

Re: OOD in Ada?

[Marin David Condic]

If you start changing Ada to have "class" constructs and object->method
syntax and so on to make the Java/C++ programmers comfortable, you're just
migrating Ada into becoming Java/C++ rather than being what it is. Assuming
you could get there at all, you'd end up having to change so many paradigms
and assumptions within the language, that it would either get broken badly
or just start being C++/Java only with some slight variations. Once you do
that, why bother with Ada at all? Why not just go use Java/C++?

It doesn't seem like it is worth it to start changing syntax and structures
that will be non-orthogonal with the rest of Ada & make existing programs
either broke or unrecognizable or confusing (New-Ada syntax or Old-Ada
syntax?). To upset the installed base of users and the installed base of
code by that much, you'd have to really believe there is some huge benefit
to be had. So far, there is no evidence that anything is that badly broke or
that changing anything is going to win thousands of new converts. If Ada is
sinking, its just re-aranging the deck chairs on the Titanic. If Ada is
growing, eventually the converts will get used to what is already there. Its
not as if these superficial things are *preventing* anyone from
accomplishing some important goal. A (possibly "ugly" in the eyes of some
beholders) solution does exist.

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


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:afab31$a4c$2@a1-hrz.uni-duisburg.de...
>
> As a first step, try one of your programs with capitals
> made lower case, and do not use a monospaced font.
> Look at your Ada++ program then :-)
>
> (Then, make keywords use a bold grotesque and identifiers
> italic (antiqua), Symbols for symbols. Look again ... :-)

Re: OOD in Ada?

[Daniel Dudley]

"Marin David Condic" wrote in message
news:afaear$84m$1@nh.pace.co.uk...
> If you start changing Ada to have "class" constructs and
> object->method syntax and so on to make the Java/C++
> programmers comfortable, you're just migrating Ada into
> becoming Java/C++ rather than being what it is. Assuming
> you could get there at all, you'd end up having to change
> so many paradigms and assumptions within the language,
> that it would either get broken badly or just start being
> C++/Java only with some slight variations. Once you do
> that, why bother with Ada at all? Why not just go use
> Java/C++?
>
> It doesn't seem like it is worth it to start changing
> syntax and structures that will be non-orthogonal with
> the rest of Ada & make existing programs either broke or
> unrecognizable or confusing (New-Ada syntax or Old-Ada
> syntax?). To upset the installed base of users and the
> installed base of code by that much, you'd have to really
> believe there is some huge benefit to be had. So far,
> there is no evidence that anything is that badly broke or
> that changing anything is going to win thousands of new
> converts. If Ada is sinking, its just re-aranging the deck
> chairs on the Titanic. If Ada is growing, eventually the
> converts will get used to what is already there. Its not
> as if these superficial things are *preventing* anyone
> from accomplishing some important goal. A (possibly "ugly"
> in the eyes of some beholders) solution does exist.

Just occasionally, someone publicly displays an incredible
amount of common sense. MDC has done so here. Thank you.

I am competent in a number of imperative, declarative and
pure O-O programming languages. Ada is not one of them, but
I am now making an effort to change that status flag.

Learning a new programming language involves understanding
its syntax, keywords and constructs (in the broadest sense),
and using these as building blocks to achieve a predefined
goal, eg. an efficient, reasonably fast and useful program
in a specific domain. The learning process also involves
understanding the language's limitations, such that one may
program efficiently with an eye to reducing the overall cost
of program development and maintenance. It costs a lot in
terms of time and money (not to mention blood, sweat and
tears) to become a competent programmer -- in any language.
Fundamental changes to language syntax and/or constructs
will only result in an increase in learning complexity and
costs, consequently they are counter-productive -- as are
'language wars'. This is not to say that a programming
language shouldn't evolve, as indeed Ada has from 83 to 95.

Ada is... well, Ada. If you don't like it, don't use it.
It's as simple as that. Now can I safely get down to the
business of learning it, without unnecessary complications?

Daniel

Re: OOD in Ada?

[Dr. Michael Paus]

steve_H wrote:
> "Dr. Michael Paus" <paus@ib-paus.com> wrote in message news:<3D1440FA.9030409@ib-paus.com>...
>  
> 
>>>2. The lack of a "dot" notation (or anything similar) for calling a member
>>>method, making the code hard to read and hard to determine where dynamic
>>>binding may be taking place.
>>
>  
> 
>>This is indeed one of the more serious problems. 
> 
> 
> I wish someone would create a new language just like Ada in everything, 
> except the OO uses the normal 'class' construct as in Java and C++.

I think it would be more worthwhile to build on Java and put in all the
nice things of Ada which are missing in Java but could be introduced
without major problems.

Michael

Re: OOD in Ada?

[steve_H]

"Dr. Michael Paus" <paus@ib-paus.com> wrote in message  
> 
> I think it would be more worthwhile to build on Java and put in all the
> nice things of Ada which are missing in Java but could be introduced
> without major problems.
 
Well, Sun is adding generics to Java, should be in JDK 1.5, I hear they 
are looking as adding some sort of limited user defined operators
for Java.  They added 'asserts' in JDK 1.4.

But no real enumeration data types like in Ada still, and probably never
well.

I think Java is good, but still Ada is better as a basic language. But 
I find Ada OO model harder to work with for me due to the different syntax 
I am used to.

Re: OOD in Ada?

[Chad R. Meiners]

"Dr. Michael Paus" <paus@ib-paus.com> wrote in message
news:3D1440FA.9030409@ib-paus.com...
> This is indeed one of the more serious problems. Many people in this group
> will argue that technically it does not make any difference whether you
have
> a "dot" notation or not and this is probably right. But from the point of
> readability it is a big difference. This may of course be just a matter of
> taste but in my daily work I have met a lot of people who have real
difficulties
> to understand what this OO stuff is all about. I think it is much easier
to
> explain and understand in a language like Java than it is in Ada.

I would argue that Ada's method is better since it requires you to
understand typing systems.  The dot notation however is very good at
allowing people think that they understand what OOP is (it's when you use
the dot notation, right? ;-).

-CRM

Re: OOD in Ada?

[Dmitry A.Kazakov]

David Crocker wrote:

> 2. The lack of a "dot" notation (or anything similar) for calling a member
> method, making the code hard to read and hard to determine where dynamic
> binding may be taking place.

Firstly, Ada has "dot" notation for objects of task and protected types.

Secondly, a "dot" notation is incompatible with multiple dispatch (several 
controlling arguments / result). Then the idea that whether an argument is 
controlled must be defined by its position is the parameter list seems not 
very good, especially for a language that has named parameter association 
and an ability to explicitly specify whether an argument is dispatching. 
Honestly it resembles FORTRAN's line continutation character that should be 
put in the sixth column of the next punched card. So I would not consider 
"dot" notation as something required by OO, rather an opposite it is a 
relic of early OO languages. However, I would wellcome some sort of 
renaming statement allowing funny:

Y := X.Sin;

for those who wants it.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: OOD in Ada?

[Kevin Cline]

"David Crocker" <dcrocker@eschertech.com> wrote in message news:<3d135676$0$8511$cc9e4d1f@news.dial.pipex.com>...
> I know that Ada95 tries to support O-O development, but from my perspective
> as an OO developer but Ada novice, it appears to me that any attempt to
> implement a large OO design in Ada will run into the following problems:
> 
> 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> classes A and B, each in its own package, such that A has a method taking a
> paremeter of type "access B", and B has a method with a parameter of type
> "access A"); 

It's possible to do this in C++ but it's seldom a good idea.  Instead
one should declare all mutually dependent classes in a single header
file, and implement them in a single source file.  

The Java requirement of a separate file for each class forces one
to physically separate classes that aren't really separable.

Excessive inter-class dependencies make many large OO programs
almost unmaintainable.

> 
> 2. The lack of a "dot" notation (or anything similar) for calling a member
> method, making the code hard to read and hard to determine where dynamic
> binding may be taking place.

The C++ community is now questioning the value of the
"dot" notation for calling member functions.  Having two different
function call notations makes generic programming more difficult.

Re: OOD in Ada?

[David Crocker]

Let me give you and others who have replied to my posting a real example of
an OO system where the "withing" problem occurs and I can't see an easy way
out of it.

A compiler is being written. The compiler has to know about objects of class
Expression and Statement. Each of these is actually an abstract class with
many descendents (because there are many types of expression etc.).

Many types of statement contain expressions (e.g. assignment statements),
therefore these Statement subclasses need to know about Expression.

Many of the expression classes also need to know about statements. For
example, an Expression has a method to generate statements to evaluate it at
run-time. The language I am compiling also allows a few types of statement
to be embedded within an expression.

What I am left with is:

Class Expression need to declare an abstract method that returns a Statement
(or another class that encapsulates a Statement). Many descendents of
Expression refer to particular descendents of Statement (e.g.
ConditionalExpression will refer to ConditionalStatement).

Many descendents of Statement contain variables of type Expression (or
Expression'class in Ada).

There is no way I want to put all the expression and statement classes in
one package! The natural way to construct the project is to put each class
in its own file (and hence package, if I am using Ada).

Things get even worse when I introduce TypeExpression.

Yes, there are lots of cross-references between classes in this application,
but these arise naturally from the nature of the problem.

--
David Crocker
Escher Technologies Ltd.
www.eschertech.com


"Kevin Cline" <kcline17@hotmail.com> wrote in message
news:ba162549.0206241203.1d375611@posting.google.com...
> "David Crocker" <dcrocker@eschertech.com> wrote in message
news:<3d135676$0$8511$cc9e4d1f@news.dial.pipex.com>...
> > I know that Ada95 tries to support O-O development, but from my
perspective
> > as an OO developer but Ada novice, it appears to me that any attempt to
> > implement a large OO design in Ada will run into the following problems:
> >
> > 1. The infamous "withing" problem (i.e. it is not possible to declare 2
> > classes A and B, each in its own package, such that A has a method
taking a
> > paremeter of type "access B", and B has a method with a parameter of
type
> > "access A");
>
> It's possible to do this in C++ but it's seldom a good idea.  Instead
> one should declare all mutually dependent classes in a single header
> file, and implement them in a single source file.
>
> The Java requirement of a separate file for each class forces one
> to physically separate classes that aren't really separable.
>
> Excessive inter-class dependencies make many large OO programs
> almost unmaintainable.
>
> >

Re: OOD in Ada?

[Marin David Condic]

That's a fair example. Is there no way you could think of it in terms of an
abstract base class - or two abstract base classes? (Base_Expression and
Base_Statement defining operations & pointers - then the actual Expression
and Statement packages descend from these & you "with" the
Base_Expression/Base_Statement as needed?)

About the only thing you'd actually need in the *spec* would be a pointer to
the (base) types. The bodies would need to know about the operations and
here it doesn't present any problem with the "with" statement.

Another thing I have done when I want a whole slew of classes that might
need to be mixed & matched is to build my class heierarchy all deriving from
a single base class that defines an access type & maybe some primitive
operations for serialization, etc. (This is similar to the structure of the
MFC - everything deriving from a base class.) Note that this pretty much
circumvents any type safety you might have had on the pointers since they
can now point to *anything* in the tree (but not stuff external to the tree,
so you get at least *some* safety.) However, it does let you work with
heterogeneous collections of stuff. (I've been tinkering with some OOD stuff
relating to the XML DOM and this is pretty much how I did it.)

MDC

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


"David Crocker" <dcrocker@eschertech.com> wrote in message
news:3d1870b0$0$8507$cc9e4d1f@news.dial.pipex.com...
> Let me give you and others who have replied to my posting a real example
of
> an OO system where the "withing" problem occurs and I can't see an easy
way
> out of it.
>
> A compiler is being written. The compiler has to know about objects of
class
> Expression and Statement. Each of these is actually an abstract class with
> many descendents (because there are many types of expression etc.).
>
> Many types of statement contain expressions (e.g. assignment statements),
> therefore these Statement subclasses need to know about Expression.
>
> Many of the expression classes also need to know about statements. For
> example, an Expression has a method to generate statements to evaluate it
at
> run-time. The language I am compiling also allows a few types of statement
> to be embedded within an expression.
>
> What I am left with is:
>
> Class Expression need to declare an abstract method that returns a
Statement
> (or another class that encapsulates a Statement). Many descendents of
> Expression refer to particular descendents of Statement (e.g.
> ConditionalExpression will refer to ConditionalStatement).
>
> Many descendents of Statement contain variables of type Expression (or
> Expression'class in Ada).
>
> There is no way I want to put all the expression and statement classes in
> one package! The natural way to construct the project is to put each class
> in its own file (and hence package, if I am using Ada).
>
> Things get even worse when I introduce TypeExpression.
>
> Yes, there are lots of cross-references between classes in this
application,
> but these arise naturally from the nature of the problem.
>
> --
> David Crocker
> Escher Technologies Ltd.
> www.eschertech.com
>
>
> "Kevin Cline" <kcline17@hotmail.com> wrote in message
> news:ba162549.0206241203.1d375611@posting.google.com...
> > "David Crocker" <dcrocker@eschertech.com> wrote in message
> news:<3d135676$0$8511$cc9e4d1f@news.dial.pipex.com>...
> > > I know that Ada95 tries to support O-O development, but from my
> perspective
> > > as an OO developer but Ada novice, it appears to me that any attempt
to
> > > implement a large OO design in Ada will run into the following
problems:
> > >
> > > 1. The infamous "withing" problem (i.e. it is not possible to declare
2
> > > classes A and B, each in its own package, such that A has a method
> taking a
> > > paremeter of type "access B", and B has a method with a parameter of
> type
> > > "access A");
> >
> > It's possible to do this in C++ but it's seldom a good idea.  Instead
> > one should declare all mutually dependent classes in a single header
> > file, and implement them in a single source file.
> >
> > The Java requirement of a separate file for each class forces one
> > to physically separate classes that aren't really separable.
> >
> > Excessive inter-class dependencies make many large OO programs
> > almost unmaintainable.
> >
> > >
>
>
>

Re: OOD in Ada?

[tmoran]

> ... build my class heierarchy all deriving from a single base class
> ... Note that this pretty much circumvents any type safety ...
  I can't phrase it well, but this bother me.  In parsing, you have a
bunch of terminals and non-terminals and a base non-terminal (something
like "program").  So make a base class of Non_Terminal with children like
"Declarative_Part", "Expression", "Term", etc.  That's the general
paradigm for a parser.
  Then you have a particular grammar that says that an Expression can have
a Statement as a constituent (in the OP's case), or that a Term can be
followed by an Adding_Operator, and so forth.  It seems to me overdoing
things to try to use the Ada type system to encode particular syntax
rules, especially when you consider that a particular grammar may change
due to changes in the language, or to arrange to call semantic routines at
more convenient times, or whatever.

Re: OOD in Ada?

[Marin David Condic]

There's more than one way to do just about anything. :-) I'm not sure I
understand where you're going with this. I'm not clear if you are in favor
of deriving some sort of syntax elements from a base class or not. What do
you mean by: "use the Ada type system to encode particular syntax rules"?
From my limited experience with parsing things, I can see how one might say
"I've got some sort of tokens or syntax elements that are on the one hand,
all the same kind of thing conceptually in that I want to build a tree of
them, but on the other hand, they're all different in that they may contain
substantially different data..."

One way I've done it and seen it done is with discriminated records. They're
all the same type so you can build linked data structures with them. Another
method is to use tagged records where the base class handles anything common
to the tree nodes and you derive new classes to add the variant parts. The
new classes are good models of each syntactic element and may need to make
reference to each other via a sort of generic pointer. (You want to be able
to chase down the parse tree and it will contain heterogeneous data...) The
only problem here is that since you're using a single pointer type to point
to a variety of different types, you do circumvent some of the type safety
you might otherwise get on the pointers. (Its somewhat worse than using a
discriminated record since some unrelated classes could be built from the
same base type & you risk having pointers that can reference something
outside of the controlled subset.)

The thing is that when you need to build two classes that might need to
reference each other, deriving from a common base type is a good way to do
that. Deciding if it is A Good Thing to have mutually referential classes is
another matter.

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


<tmoran@acm.org> wrote in message
news:UxnS8.606$ci5.107953341@newssvr13.news.prodigy.com...
>   I can't phrase it well, but this bother me.  In parsing, you have a
> bunch of terminals and non-terminals and a base non-terminal (something
> like "program").  So make a base class of Non_Terminal with children like
> "Declarative_Part", "Expression", "Term", etc.  That's the general
> paradigm for a parser.
>   Then you have a particular grammar that says that an Expression can have
> a Statement as a constituent (in the OP's case), or that a Term can be
> followed by an Adding_Operator, and so forth.  It seems to me overdoing
> things to try to use the Ada type system to encode particular syntax
> rules, especially when you consider that a particular grammar may change
> due to changes in the language, or to arrange to call semantic routines at
> more convenient times, or whatever.

Re: OOD in Ada?

[tmoran]

> deriving some sort of syntax elements from a base class or not. What do
> you mean by: "use the Ada type system to encode particular syntax rules"?
   I presume the OP wants to have things along the line of

     type Adding_Operator is tagged record ...
       Op_Char : character;
     end record;
     type Simple_Expression is tagged record
       Left : Access_Simple_Expression;
       Add_Op : Access Adding_Operator;
       Right  : Access_Term;
     end record;

etc. and the problem is this can't be broken into one class = one package
because of mutual references.
  The alternative under discussion has

     type Non_Terminal is abstract tagged null record;
     type Access_Non_Terminal is access all Non_Terminal'class;

     type Simple_Expression is new Non_Terminal with record
       Components : List_Of_Non_Terminals;
     end record;

and so forth, and there's no problem with separate packages because
everything refers back to the base class Non_Terminal.  In the OP's
scenario, the compiler will catch, as a type mismatch, an attempt to set
The_Simple_Expression.Right := Access_Adding_Operator;
In the alternative, the compiler won't know that
The_Simple_Expression.Components(3) := Adding_Operator'access
is a mistake and thus the compiler can't warn you.

  It seems to me that the type system of a program should be rather basic
and one should at least hope there are no, or minimal, changes during
development.  The particular BNF for a language, in my experience, may
however be modified quite late in the game.  You may actually want to
modify the language you are parsing, or, more commonly, you want to
relabel and shuffle around some things so that certain productions are
recognized, and call semantic routines, at slightly different points.
For instance, you might want to change

  simple_expression : term       {process_term($1);}
    | simple_expression adding_operator term  {add_expr($1,$2,$3);}
to
  simple_expression : term       {calculate_term($1);}
      | first_part term          {apply_op_to($2);}
  first_part :  simple_expression adding_operator {push_then_note_op($2);}

  The more closely the BNF is mapped to the types, the more any simple
change to the BNF will require changes to the types.  Worse, if the types
are one-one mapped to packages, even the package structure of the program
must change.  The likelihood of such changes late in development seems to
me a very bad idea.

  In the Access_Non_Terminal version you do indeed lose compiler type
checking.  But in this sort of app, the parser is supposed to be
guaranteeing that only legitimate things get stored, eg, the parser
should disallow "2 + -" and thus the semantic routine add_expr will
never be called with its third parameter an adding operator.
So giving up type checking is not much of a loss.

Re: OOD in Ada?

[Marin David Condic]

O.K. I understand where you were going with it now. I'd agree that trying to
make everything in a parse tree as you describe it use the type system to
try to guarantee correctness is a bad idea. Attempting to do so is only
likely to lead to fighting with the compiler endlessly & for little
advantage. Better to have the parser logic insure that only a correct parse
tree gets built & use a more loose level of type checking on the access
types.

It still leaves a hole in that someone could derive from the base class and
succeed in getting something into the parse tree that is incorrect - but
doing so would require some rather deliberate moves. The answer can be "Then
just don't do that!" because it isn't likely to happen just by an accidental
coding error.

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


<tmoran@acm.org> wrote in message
news:fKIS8.801$X14.133162217@newssvr13.news.prodigy.com...
>    I presume the OP wants to have things along the line of
>
>      type Adding_Operator is tagged record ...
>        Op_Char : character;
>      end record;
>      type Simple_Expression is tagged record>        Left :
Access_Simple_Expression;
>        Add_Op : Access Adding_Operator;
>        Right  : Access_Term;
>      end record;

>
<snip>

Re: OOD in Ada?

[Hyman Rosen]

David Crocker wrote:
> There is no way I want to put all the expression and statement classes in
> one package! The natural way to construct the project is to put each class
> in its own file (and hence package, if I am using Ada).

Keeping in mind that I don't know Ada, isn't this what child packages are for?
Declare the base expression and statement classes in a package, and put each
descendant in its own child package.

Re: OOD in Ada?

[Jim Rogers]

Hyman Rosen wrote:

> David Crocker wrote:
> 
>> There is no way I want to put all the expression and statement classes in
>> one package! The natural way to construct the project is to put each 
>> class
>> in its own file (and hence package, if I am using Ada).
> 
> 
> Keeping in mind that I don't know Ada, isn't this what child packages 
> are for?
> Declare the base expression and statement classes in a package, and put 
> each
> descendant in its own child package.
> 


That is one of the things hierarchical packages are for.
Note that use of hierarchical packages exposes public and private
package members differently than developing type hierarchies in
unrelated separate packages.

Also remember that the Ada package provides an equivalent to the
C++ namespace. It is certainly NOT reasonable to restrict
a namespace to contain only one class in C++. In the same way,
it is often beneficial to combine several type definitions in a
single Ada package.

Jim Rogers

Re: OOD in Ada?

[Marin David Condic]

I'm not sure all the newsgroup data is getting through. I've outlined
basically that twice & maybe the OP isn't seeing it.

You can use child packages or non-child packages that inherit from some base
class. The important thing is that as long as the subclasses inherit from a
base class you can have an access value to anything within the class
heierarchy - hence classes "A" and "B" can have references to each other.

A good example of this is the XML DOM - You start with a base class called
"Node" which doesn't represent any actual elements in the DOM tree, but
defines some common characteristics. (Perfect case for an abstract class.)
All other elements of an XML document are represented as a derived class
from this base class. Since many of the XML document elements contain other
elements that might be composed of yet other elements of all sorts of types,
you need to have them able to hold references to each other but without the
"withing problem". The base class of type "Node" fixes this - you have an
access type that can reference anything of type Node'Class & then you're
stardust.

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


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:Dl8S8.26239$cE5.16490@nwrddc02.gnilink.net...
>
> Keeping in mind that I don't know Ada, isn't this what child packages are
for?
> Declare the base expression and statement classes in a package, and put
each
> descendant in its own child package.
>

Re: OOD in Ada?

[Fraser Wilson]

"David Crocker" <dcrocker@eschertech.com> writes:

> There is no way I want to put all the expression and statement classes in
> one package! The natural way to construct the project is to put each class
> in its own file (and hence package, if I am using Ada).

Put just the abstract base classes for Expressions and Statements in
the same package, and put derived classes in their own packages.  You
could use child packages for this.

My compiler is structured along these lines:

   package Trees;   --  abstract base class for tree node
   package Trees.Expressions;
   package Trees.Expressions.Operators;
   -- ...
   package Trees.Statements;
   package Trees.Statements.Ifs;
   -- enzofoort

You get the idea.  If it turned out that expressions and statements
were mutually dependent, I would have either put them both in the same
package, or have only the package bodies rely on each other (which you
can do by casting down at run time -- not really recommended, but
nevertheless useful).

Fraser.

Re: OOD in Ada?

[Randy Brukardt]

Fraser Wilson wrote in message ...
>"David Crocker" <dcrocker@eschertech.com> writes:
>
>> There is no way I want to put all the expression and statement
classes in
>> one package! The natural way to construct the project is to put each
class
>> in its own file (and hence package, if I am using Ada).
>
>Put just the abstract base classes for Expressions and Statements in
>the same package, and put derived classes in their own packages.  You
>could use child packages for this.
>
>My compiler is structured along these lines:
>
>   package Trees;   --  abstract base class for tree node
>   package Trees.Expressions;
>   package Trees.Expressions.Operators;
>   -- ...
>   package Trees.Statements;
>   package Trees.Statements.Ifs;
>   -- enzofoort
>
>You get the idea.  If it turned out that expressions and statements
>were mutually dependent, I would have either put them both in the same
>package, or have only the package bodies rely on each other (which you
>can do by casting down at run time -- not really recommended, but
>nevertheless useful).


This is a fine solution, but it runs into a problem in use: essentially
every reference to anything will need a type conversion to the "real"
type in order to access the operations/components. (This happens a lot
in the Claw Builder, and it gets really old, especially in a
"use"-adverse environment, because the type conversions make the code
much harder to read.)

That is why the ARG has spent so much time on the various proposals
here, and finally appears to have settled on the "type stub" approach.

               Randy Brukardt

Re: OOD in Ada?

[Fraser Wilson]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> This is a fine solution, but it runs into a problem in use: essentially
> every reference to anything will need a type conversion to the "real"
> type in order to access the operations/components.

There's a certain amount of that, yes.  But most of the work is done
with dispatch: one subprogram does the semantic analysis, another does
the code generation, and most of the time you can make the call
without worrying about what the tree node really is (even if you
secretly know).

For example, an if statement node has an element called "Condition",
and when checking an if statement, a call like Check
(If_Statement.Condition) suffices.  You know and I know that it's
really an expression, but I don't have to encode that knowledge.  In
general, the parse tree has been able to avoid type conversions; the
other class hierarchies (symbol table entries and types) aren't so
pretty.

Dispatching operations on the root tree node type have to be carefully
chosen of course.  And that can get a bit silly: in the class
hierarchy for symbol table entries, one of the operations is
"Push_Address" which only makes sense for variables and subprograms,
so any time you call this operation you have to know what you have.
Perhaps a conversion is better in this case, to make that knowledge
explicit (since unlike the parse tree, it's being relied upon).

cheers,
Fraser.

Re: OOD in Ada?

[Stephen J. Bevan]

"David Crocker" <dcrocker@eschertech.com> writes:
> Let me give you and others who have replied to my posting a real example of
> an OO system where the "withing" problem occurs and I can't see an easy way
> out of it.
> 
> A compiler is being written. The compiler has to know about objects of class
> Expression and Statement. Each of these is actually an abstract class with
> many descendents (because there are many types of expression etc.).

There seems to be two schools of thought about how best to structure a
compiler :-

* The "OO" way in which a base class is defined for various syntactic
  elements such as Expression and Statement and then subclasses are
  defined for specific instances such as IfStatement, ... etc.

* The "old" way by defining a record for any syntactic units of
  interest and use case to cover variants.

The "OO" way has an advantage if your implementation strategy is fixed
but the language is changing since you can add new nodes without
disturbing other code: just subtype and implement the required
methods.

The "old" way has an advantage if your language is fixed but your
implementation strategy is not i.e. you may start out with some
strategy and then realise that an extra pass could be used to do some
othe sort of analysis/optimisation.  That's because you can add a new
phase without having to touch the nodes or the other phases (just the
code where you plug the new phase in).

From your example it isn't clear to me which situation you are in,
though statistically I would guess you have a fixed language.  In that
case I'd just stick with the "old" way of doing things and avoid
classes completely.  Some recommend sticking with the "OO" style but
using some flavour of visitor to avoid having to touch so many classes
should a new phase need to be added.  However, it isn't clear to me
how this is an improvement over the "old" way of doing things.

This is probably not the answer you are looking for but it is how I'd
solve your problem.

Re: OOD in Ada?

[Craig Carey]

On Fri, 21 Jun 2002 17:39:07 +0100, "David Crocker"
   <dcrocker@eschertech.com> wrote:
>I know that Ada95 tries to support O-O development, but from my perspective
>as an OO developer but Ada novice, it appears to me that any attempt to
>implement a large OO design in Ada will run into the following problems:
>
>1. The infamous "withing" problem (i.e. it is not possible to declare 2
>classes A and B, each in its own package, such that A has a method taking a

If it is about 'methods' then there might not be a withing problem. What
about Java: has that got a withing problem(?).

>paremeter of type "access B", and B has a method with a parameter of type
>"access A"); and
...
>
>So: is there anyone on this list who does serious object-oriented
>development in Ada and would like to comment?

There are comments on resolving the withing problem in this HTML record
of a February 2002 ARG meeting:

http://www.ada-auth.org/ai-files/minutes/min-0202.html


On Fri, 28 Jun 2002 18:57:11 -0500, "Randy Brukardt"
    <randy@rrsoftware.com> wrote:
...
>Well, the good news is that while this was being debated here, the ARG
>was meeting in Vienna. And we approved (to my great surprise)
>AI-00217-04. So we have a "final" solution. How long it will be before
...
>(I haven't posted the final update to the AI yet.)

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00217.TXT


--

The first poster wrote about a withing problem with "methods". That
sounds like there may have been an idea that packages with procedures
calling each other can't all be with-ed together.

It is possible to have 4 child package bodies that call subroutines named
in the other three bodies. The code below shows two package bodies
withing each other.

Another obvious option is to use unchecked conversions on pointers (or on
records, with something like Gnatmake's "-gnatR" option saying how many
bytes the compiler would allocate, and then the programmer can add a
safety margin and unchecked conversions can allow a field can be
resevered in a record for a type that has not yet been defined). Avoiding
the use of pointers can speed a progam up a little.

Here is some code showing that use of child packages can get around a
withing problem that is not a withing problem with types.

Below is demonstration of how to put more than one case statement in a
variant record allowing bypassing of the problem of the compiler saying
that a field named "X" can not be defined in more than one "when"
alternative.

The program produces this output:

  Cycles of P.A.FA & P.B.FB return 11.00500500000000000
  Excessive = FALSE

The pointer to the task is made to be a pointer to a null record inside
of package P, because package P does not with package Q, and Q is the
package that defines the task type.

-begin-
--------------------------------------------------------------------
with Ada.Text_IO;
with P;
with P.A;
with Q;

procedure Main is
   package Tio renames Ada.Text_IO;
   package Rio is new Tio.Float_IO (Num => P.Real_R);
   G     : P.G_Type_Ptr;
begin
   G := new P.G_Type'(P.Heavy,
               Q_Task => P.Hoof_Ptr_Type'(P.Heavy, null),
               Excessive => False);
   Q.Start_Up_New_Task (G => G.all);
   P.Free (G);
   Tio.Put ("Cycles of P.A.FA & P.B.FB return ");
   Rio.Put (P.A.FA (1.0), Exp => 0);
   Tio.New_Line;
end Main;
--  "gnatmake main.adb -gnatl -gnata -gnatq -gnato -gnatf -v -gnatU
--  -O0 -g -gnaty3abcefhikrlM79pt -gnatwa -bargs -E -p -we -static
--  -largs  -v -v -L. >@.adl"

--------------------------------------------------------------------
with P;
pragma Elaborate_All (P);

package Q is

   type Q_Task is limited private;
   type Q_Task_Ptr is access Q_Task;

   procedure Start_Up_New_Task (G : in out P.G_Type);

   function IfElse is new P.IfElse_G (T => P.Real_R);

private
   task type Q_Task is
      entry Activate (G : P.G_Type);
   end Q_Task;
end Q;
--------------------------------------------------------------------
with Ada.Unchecked_Conversion;
with Ada.Text_IO;
with P;

package body Q is
   task body Q_Task is
      Excessive : Boolean;
   begin
      accept Activate (G : P.G_Type) do
         Q_Task.Excessive := G.Excessive;
      end Activate;
      Ada.Text_IO.Put_Line ("Excessive = " & Boolean'Image (Excessive));
   end Q_Task;

   function From_Task is new Ada.Unchecked_Conversion (
            Source => Q_Task_Ptr,
            Target => P.Hoof_Ptr);

   function To_Task is new Ada.Unchecked_Conversion (
            Source => P.Hoof_Ptr,
            Target => Q_Task_Ptr);

   procedure Start_Up_New_Task (G : in out P.G_Type) is
   begin
         --  An unchecked conversion of a pointer to a task gets
         --  around the 'withing (of types) problem'
      G.Q_Task.Ptr := From_Task (new Q_Task);
      To_Task (G.Q_Task.Ptr).Activate (G);
   end Start_Up_New_Task;
end Q;
--------------------------------------------------------------------
with Ada.Unchecked_Deallocation;
with System;

package P is

   type Hoof is limited null record;
   type Hoof_Ptr is access Hoof;
   type Mode_Enum is (Light, Medium, Heavy);

   type Hoof_Ptr_Type (Mode : Mode_Enum) is
      record
         case Mode is
            when Light => null;
            when Medium  | Heavy =>
               Ptr   : Hoof_Ptr;
         end case;
      end record;

   type G_Type (Mode : Mode_Enum) is
      record
         Q_Task   : Hoof_Ptr_Type (Mode);
         case Mode is
            when Light | Medium => null;
            when Heavy =>
               Excessive : Boolean;
         end case;
      end record;

   type G_Type_Ptr is access all P.G_Type;

   procedure Free is
         new Ada.Unchecked_Deallocation (P.G_Type, G_Type_Ptr);

   generic
      type T is private;
   function IfElse_G (B : Boolean; P, Q : T) return T;

   type Real_R is digits System.Max_Digits;

end P;
--------------------------------------------------------------------
package body P is
   function IfElse_G (B : Boolean; P, Q : T) return T is
   begin
      if B then return P; else return Q; end if;
   end IfElse_G;
end P;
--------------------------------------------------------------------
package P.A is
   function FA (X : Real_R) return Real_R;
end P.A;
--------------------------------------------------------------------
with P.B;
with Q;

package body P.A is
   function FA (X : Real_R) return Real_R is
   begin
      return Q.IfElse (X <= 10.0, P.B.FB (X + 1.0) + 0.001, X);
   end FA;
end P.A;
--------------------------------------------------------------------
package P.B is
   function FB (X : Real_R) return Real_R;
end P.B;
--------------------------------------------------------------------
with P.A;  --  Note that the body of B needs the spec of A, and the
           --  body of A needs the spec of B. There 
          
package body P.B is
   function FB (X : Real_R) return Real_R is
   begin
      if X <= 10.0 then return A.FA (X + 1.0) + 0.000001;
      else return X;
      end if;
   end FB;
end P.B;
--------------------------------------------------------------------
-end-


Gnatchop.exe can be run on the above to split it into pieces
(method: "gnatchop <filename>").



Craig Carey
Ada mailing lists: http://www.ijs.co.nz/ada_95.htm