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,ad62d6b425bebfec X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: "use" clauses and Ada 95 OOP Date: 1996/07/19 Message-ID: #1/1 X-Deja-AN: 168997597 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-07-19T00:00:00+00:00 List-Id: In article <31EF9D30.7A0@csehp3.mdc.com> "James A. Squire" writes: > Mitch Gart wrote: >... > > To me the C++/Java syntax > > > > x.func > > > > seems clearer than the Ada syntax in this case because what is being > > called is the function that is associated with X at runtime, rather than > > the function that comes from a given package. > > Indeed, that is a drawback that was mentioned in our group by someone > who is familiar with C++. I can't argue with it at all. What do either of you mean by "the function that is associated with X at runtime" here? In the environment we are talking about here there is no "_the_ func associated with X". X contains a value which will have a type indicator which will provide access to the proper jump table entry. Since the value of X can change (e.g., in C++ or Java up level assignments) the func "associated" with X can change (and not necessarily be the one defined in the class of which X was a declared instance). Seems pretty much like the exact same issue. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com