Re: 'withing' problem

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

I'm just voicing my support for Simon here. Forcing tools to break
withing cycles is a bad idea. The "with type" extension in GNAT is a
good way to solve the problem. 

Apparently there are some issues with it that make it not a good idea
in general; I hope that either a replacement is found soon, or that
the ARG decides that the benefits outweigh the problems.


Simon Wright <simon@pushface.org> writes:

> "Matthew Heaney" <mheaney@on2.com> writes:
> 
> > "Simon Wright" <simon@pushface.org> wrote in message
> > news:x7vy9lbxih0.fsf@smaug.pushface.org...
> > > I think that people looking at this model, perhaps for the purpose of
> > > maintaining code written to implement it, need to have a very clear
> > > idea of how the code will look.
> > 
> > My philosophy is, if you want to have a good idea how the code will look,
> > then you should look at the code...  In any case, you should just ignore the
> > forward declaration package, as it's just syntactic overhead that has no
> > bearing on your model of the problem.
> > 
> > > It's a Bad Thing if you need to make arbitrary decisions to break
> > > cycles.
> > 
> > You haven't explained why arbitrary decisions are bad, so this isn't a very
> > cogent argument, which just reduces to "I don't like it, so it's bad."
> 
> Well, "arbitrary" translates roughly to "unpredictable", "surprising"
> both of which are definitely bad (I think so, anyway).
> 
> > And besides, this solution is no different from other areas of the language.
> > For example, if you want to declare a recursive pair of subprograms, then
> > you have to forward declare one of them (and it's arbitrary which one):
> 
> Here, you can "arbitrarily" (or following the warnings given by
> -gnaty) forward declare _both_ (ie, _all_) subprograms. Symmetric.
> 
> > > What would be even worse would be to have a framework code generator
> > > that applied heuristics to break cycles. I imagine that it wouldn't
> > > take much for such heuristics to make the opposite decision for minor
> > > model changes (remember that very few models are as simple as this
> > > one!)
> > 
> > Let's concentrate on real problems.  John Volan couldn't figure out
> > how to declare two mutually dependent abstractions in two separate
> > packages.  I showed how to do this.  Problem solved.
> 
> This topic is a real problem for me.
> 
> 
> Does your Patient_Forward solution extends to declaring Doctor_Forward
> similarly? I get trouble at
> 
>    procedure Visit_Doctor
>      (Patient : in out Patient_Type;
>       Doctor  : in out Root_Doctor'Class) is
>    begin
>       Treat_Patient (Doctor, Patient);
> patients.adb:9:22: expected type "Doctor_Type" defined at doctors.ads:6
> patients.adb:9:22: found type "Root_Doctor'Class" defined at doctors_forward.ads:3
>    end;
> 

-- 
-- Stephe