Re: OOD in Ada?

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

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