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/23 Message-ID: #1/1 X-Deja-AN: 170446575 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-07-23T00:00:00+00:00 List-Id: In article schmid@alta.ide.com (Stephen Schmid) writes: [good stuff on why x.func has basically the same "problem" as that pointed out for Ada func(x) ... snipped] > the use clause. With the use clause, the reader has no clue as to > which function is being called without checking the context clauses, and > there is greater opportunity for error. You are giving the reader _less_ > information, which cannot be helpful. Including the package name gives > the reader a starting point to determine what functions may be called at > runtime. In a language with run-time dispatching, that is the most that > you can do. Part of the issue here revolves around the fact that one of the features of dynamic polymorphism is that you not only don't know what will be called you are supposed to _like_ this aspect. One possible "compromise" that some people advocate is to always provide an "abstract base" for any new extension introducing new operations (not overrides). Then you always make a dispathing call on such operations via the abstract version (including the package name). The idea is that a) you will show which "sort" of operation is being called (by the qualified name), and b) you will know that it isn't the exact one named (which is abstract) so that it won't "look odd" or whatever. Just a thought... /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com