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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,93fa00d728cc528e X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,93fa00d728cc528e X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-10-27 11:25:59 PST Newsgroups: comp.lang.ada,comp.object Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!sgigate.sgi.com!enews.sgi.com!wdl1!dst17!mab From: mab@dst17.wdl.loral.com (Mark A Biggar) Subject: Re: Generic association example (was Re: Mutual Recursion Challenge) Message-ID: <1994Oct27.143754.27957@wdl.loral.com> Sender: news@wdl.loral.com Organization: Loral Western Development Labs References: <1994Oct24.203214.4967@swlvx2.msd.ray.com>> <1994Oct26.232154.29094@swlvx2.msd.ray.com> Date: Thu, 27 Oct 1994 14:37:54 GMT Xref: nntp.gmd.de comp.lang.ada:16236 comp.object:16685 Date: 1994-10-27T14:37:54+00:00 List-Id: In article <1994Oct26.232154.29094@swlvx2.msd.ray.com> jgv@swl.msd.ray.com (John Volan) writes: >But I still see a problem: It looks like each class is giving up the >ability to use static strong typing to assert the exact type of the >*other* objects associated with it. In other words, a "Person-who- >can-occupy-an-Office" can't assert that it's associated with an >"Office-that-can-be-occupied-by-a-Person" (or with a "Total Office", >for that matter). All it can say is that it's associated with an >"Office". So when a client asks a Person object for its Office, the >Person can answer with its associated "Office", but it can't provide >the client with a "Total" view of that Office. The client would have >to do the view-conversion itself by "narrowing" (safely downcasting) >that Office into a "Total Office". > >That narrowing operation would incur a run-time check on the Office's >tag. But that check is actually redundant. You know and I know that >the Office object will really be a "Total Office"; we can assert that >as a statically-determined fact, since we're the designers of the >software, and that was our original intent for the association. >However, when we go to write our Ada code for the Person class, we >discover that we can't explicitly assert, in the Ada code itself, that >a Person's associated Office will actually be one of those "Total >Offices". So we can't tell the compiler that this is a >statically-determined assertion that it can check statically. >Instead, it becomes a dynamically-checked assertion. In short, this >takes us a step away from a statically-checked style of programming, >and moves us closer to the dynamically-checked style of languages such >as Smalltalk. > >I suppose we could apply a pragma Suppress at some point to eliminate >the extra dynamic check, once the program was fully tested. But, more >to the point, we've lost a certain amount of expressibility. Since >the Ada code doesn't directly express what we mean, its readability by >other Ada programmers (for example, maintainers) is reduced. Actually this case is not a real problem, as a smart compiler can optimize the run time check away. Any "Narrowing" downcasting from an abstract type to its first non-abstract decendent will always pass the check, and so the check need not be done, even without the pragma Suppress. -- Mark Biggar mab@wdl.loral.com