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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,900edaa189af2033 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Ada95 OOP Questions Date: 1996/08/06 Message-ID: X-Deja-AN: 172453294 references: <4u4ln3$fur@mailsrv2.erno.de> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-08-06T00:00:00+00:00 List-Id: Thomas said "code. Using use here leaves you with no clue at all! And this "confusing" point is not peculiar to dispatching calls: it occurs with Ada 83 derived types as well. Not new, although the "search direction" is reversed in that case.)" Actually derived types are a little more problematical than that for the "i never use use, all I have is grep" crowd. If you forbid the use of USE you can still find a procedure call in your program xyz (a,b,c) where xyz is nowhere in sight, it is not in the unit where the call occurs, and it is not in any of the directly with'ed units. This happens if you derive a type from say an exported subtype, you derive all the primitive operations, and they are directly visible locally. So grep will not be enough, even if you ban USE. Really you need decent tools to build Ada programs, and relying on grep for locating defining occurrences of subprogram references is pretty miserable (note for example that it fails in any case in the overloaded case). It is hard for me to believe that there are Ada environments with no better capabilities than grep for finding things. With GNAT, you have two possibilities. For static analysis, you can use gnatf, and then if you like, use the emacs interface to get straight from applied to defining occurrences. (note that soon we will integrate gnatf with gnat1 making this possibility a bit more convenient). Second, you can follow the call with gdb, which has the advantage of course of being a dynamic trace that follows dispatching calls. GDB will then point right at the appropriate source location. As to whether using dynamic dispatching makes programs less maintainable, we do not have enough experience to know. There are isolated anecdotal discussions on each side (one entertaining one was that the green design team very specifically avoided introducing dynamic dispatching because they had used Simula-67 extensively, and found exactly that large complex Simula-67 programs were hard to maintain -- but that's just one experience point, with one kind of application). Like any other feature, there is a wide range from good-use to ab-use and it remains to be seen where on this range typical OO applications will sit when the entire life-cycle costs for large projects are considered. It is interesting though to see a very clear statement that the motivation for banning use clauses is entirely tool driven in this case, or rather we should say driven by lack of tools. It is interesting to wonder how the use of USE clauses would be affected by good tools. My preference is to write code that is unambiguous without any use of qualification, i.e. to avoid reusing the same names in different packages, because I think that is potentially confusing anyway. Then the code you write can always be displayed with dots if you prefer dots -- dotted code cannot necessarily be converted to non-dotted form. Two tools would be useful in a compiler, both are on the thought list for possible GNAT additions. 1. An option to ensure that even though you use dots, your references would be unambiguous without them. 2. a dotifier tool Of course I realize that if you are a confirmed anti-use person, then you choose names differently, but I still find the package names and dots to have a rather high noise-to-signal ratio when reading code. A lot dpeends on the program. For example in GNAT, where generally you need to be reasonably familiar with the structure of the front end to read the code anyway, the compiler itself is written using USE, and you quickly learn where things are (for example Analyze_Object_Declaration is obviously in Sem_Ch3, the package that handles chapter 3 semantics, and we really do not need to write Sem_Ch3.Analyze_Object_Declaration). On the other hand, the run time library, with its 569 separate source files, is a place where it is useful to use qualification extensively. We never use USE in library specs (this is actually enforced by the compiler to some degree), and use them only some of the time in library bodies for units that are clearly intimately related, or very familiar. As in all style matters, I don't like absolute rules, and for sure it is annoying to see programs use units that have been designed for use without USE and insisting on not using the USE, giving us highly useful names like Posix.Posix_Error :-)