From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,99f33f51845a7793 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-16 06:38:44 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: 'withing' problem Date: 16 Nov 2001 09:37:37 -0500 Organization: NASA Goddard Space Flight Center Message-ID: References: <3be27344$0$227$ed9e5944@reading.news.pipex.net> <3BE42900.7590E899@adaworks.com> <3be65f4c$0$237$ed9e5944@reading.news.pipex.net> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1005921606 7203 128.183.220.71 (16 Nov 2001 14:40:07 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 16 Nov 2001 14:40:07 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Xref: archiver1.google.com comp.lang.ada:16624 Date: 2001-11-16T14:40:07+00:00 List-Id: 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 writes: > "Matthew Heaney" writes: > > > "Simon Wright" 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