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: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Design By Contract Date: 1997/09/05 Message-ID: #1/1 X-Deja-AN: 269989318 References: Organization: Estormza Software Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: In article , nospam@thanks.com.au wrote: >One obvious weakness of Ada child packages compared with Eiffel selective >export is a lack of symmetry. With selective export, two modules can >selectively export to each other. It's difficult to imagine how you could do >this elegantly with child packages, if at all. > >It may be necessary in Ada to co-encapsulate under such circumstances. In >that case, you lose the ability to control how each object updates the other's >state. This issue is frequently debated on comp.lang.ada, but I'll mention it again. The _reason_ modules and types are orthogonal is precisely so you can co-encapsulate types in the same package; this is why no "friend" instruction is needed in Ada. If two types need access to each other's state, then they are highly cohesive abstractions, and _should_ go in the same package. The argument that by using this idiom one "loses the ability to control how each object updates each other's state" isn't an issue in real programs. If such control were an issue, then perhaps the reason is that the abstractions are too large or complex. See John Volan's discussion about Ada's with'ing problem: -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271