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: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: "use" clauses and Ada 95 OOP Date: 1996/07/23 Message-ID: #1/1 X-Deja-AN: 169787091 references: organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-23T00:00:00+00:00 List-Id: "But my point is that a naive Ada 95 reader might think that the call pkg1.func(x) calls the code that is in the body of pkg1." Well naive readers can be confused in many ways, and one possible solution is to de-naiveify the readers :-) If people get compile time visibility and run time dispatching access mixed up, they are missing a fundamental principle, and will run into other problems. I really don't see a problem, if you don't like the above, don't use it and use USE clauses instead. You can't have it both ways, if you want to emphasize visibility aspects by not using USE, then you are clearly going to have this clash. In C++, when you "import" a type, you get all its methods visible, i,e the primitive operations in Ada terms. If you want this effect in Ada, you use USE, if you don't want it, you don't use USE. Seems simple enough to me. P.S. I really do not know namespaces in C++ at all, do they allow this same separation of visibility from run time accessibility (if not I would say that is a disadvantage, not an advantage). What you have in Ada is a choice of two approaches. I personally have no trouble with the notation above pkg1.func(x), but if you feel that naive readers of your code *will* have trouble with this notation, then by all means don't use the notation! People who have learned to be 100% allergic to USE in Ada 83 will find some discomfort here, but that's something they bring upon themselves. The idea behind disallowing USE clauses is that it is a GOOD THING if it is made VERY clear at the source level EXACTLY where the subprogram being called is defined. BUT! the whole idea of dynamic dispatching is to make absolutely sure that you can NOT tell at the source level where the subprogram being called is declared. There is no clash between dynamic dispatching and the design of Ada, there is a clash between dynamic dispatching and an insistence on never using the USE clause, and that is really what Mitch is pointing out. This really has nothing to do with f(x) vs x.f, since these notations are equivalent, it has to do with whether or not you want to make visiility explicit at the source code level. Neither f(x) nor x.f does this, but package.f(x) does make this explicit (there is no obvious syntactic analog in the x.f case).