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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,56dbd715fa74735a X-Google-Attributes: gid103376,public From: matthew_heaney@acm.org (Matthew Heaney) Subject: Re: Mutually dependent private types Date: 1998/05/22 Message-ID: #1/1 X-Deja-AN: 355713343 Content-Transfer-Encoding: 8bit References: <6k4b7t$vhn$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Network Intensive Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-05-22T00:00:00+00:00 List-Id: In article <6k4b7t$vhn$1@nnrp1.dejanews.com>, adam@irvine.com wrote: >> I read John's paper, but I don't find his argument convincing. Doesn't the >> following code solve the putative with'ing "problem"? > >I think John's objection to this solution is that it requires a >runtime check to make sure the second parameter has the correct type. There are many, many times when a run-time check is required. For example, declare X : Integer := ...; begin X := X + 1; end; requires a run-time check. >Also, one could object on philosophical grounds that requiring the two >packages to be children of a common parent isn't appropriate for >packages that really don't have much of a common purpose. (Then >again, I suppose that with every language there are cases that require >one to write code that goes against software engineering philosophy.) Perhaps so, but it was the constraints of your particular problem that necessitated that structure. Specifically, you required each type to have knowledge of the representation of the other. Had your problem been, Can we have types in different packages that take the other type as an argument in the spec?, then the answer is yes, and making them children of a common root would not have been required.