* Elimination of "use" clauses @ 1999-07-01 0:00 Dr. Neil C. Audsley 1999-07-01 0:00 ` czgrr ` (3 more replies) 0 siblings, 4 replies; 64+ messages in thread From: Dr. Neil C. Audsley @ 1999-07-01 0:00 UTC (permalink / raw) We have a lot of Ada source that "with"s and "use"s a lot of packages -- to the extent that it is difficult and time-consuming to find out which package a procedure is actually from. Ideally, we would like to eliminate "use" clauses, necessitating the replacement of each procedure call X by PackageName.X instead. Is there a tool that does this? -- ========================================================================= Dr. Neil C. Audsley Email: neil@cs.york.ac.uk Senior Research Fellow Phone: +44-1904-432787 Department of Computer Science, Fax: +44-1904-432708 University of York, York. Y01 5DD, UK ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-01 0:00 Elimination of "use" clauses Dr. Neil C. Audsley @ 1999-07-01 0:00 ` czgrr 1999-07-01 0:00 ` Ted Dennison 1999-07-01 0:00 ` Samuel T. Harris ` (2 subsequent siblings) 3 siblings, 1 reply; 64+ messages in thread From: czgrr @ 1999-07-01 0:00 UTC (permalink / raw) In article <377B5807.88B875E0@cs.york.ac.uk>, Neil.Audsley@cs.york.ac.uk wrote: > Ideally, we would like to eliminate "use" clauses, necessitating the > replacement of each procedure call X by PackageName.X instead. > Is there a tool that does this? I don't know about a tool to do it automatically, but it would seem that the easiest way to do it manually, if you have to, is to remove one "use", recompile all and see what fails. Add in "package_name."s until everything compiles again, and repeat for all "use"s. If you are using a compiler which has an "Show definition of..." operation (like ObjectAda, for example), you can use that to find the package that a function call is in, but this may be more tedious than getting the compiler to find them all for you. P.S. Watch out for operators. Having added all the "package_name."s, it sometimes makes for better readability if you re-introduce the "use" (globally or in specific routines) solely for the purpose of accessing operators. Remember to comment it as such. P.P.S. Totally my opinion here, and I'm sure that a discussion of some sort will ensue as a result of this, but I believe that if one package is heavily accessed in another, then that normally justifies having a "use". Similarly, if there is a globally used, low-enough-level package (like one for a program-wide set of base declarations), then I "use" that package everywhere that I "with" it as standard. But it's up to you. Cheers, czgrr -- No email, please - reply to the newsgroup. My opinions are not necessarily those of my employer. Use any suggestions at your own risk. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-01 0:00 ` czgrr @ 1999-07-01 0:00 ` Ted Dennison 1999-07-02 0:00 ` czgrr 0 siblings, 1 reply; 64+ messages in thread From: Ted Dennison @ 1999-07-01 0:00 UTC (permalink / raw) In article <7lfvbk$fhh$1@nnrp1.deja.com>, czgrr <czgrr@my-deja.com> wrote: > In article <377B5807.88B875E0@cs.york.ac.uk>, > Neil.Audsley@cs.york.ac.uk wrote: > > Ideally, we would like to eliminate "use" clauses, necessitating the > > replacement of each procedure call X by PackageName.X instead. > > Is there a tool that does this? > > P.S. Watch out for operators. Having added all the "package_name."s, it > sometimes makes for better readability if you re-introduce the "use" > (globally or in specific routines) solely for the purpose of accessing > operators. Remember to comment it as such. Good point. But as a fellow "use-phobe", I think Neil would probably prefer to put in "use type" statements to get access to the comparison and mathematical operators that he will loose when the "use" clauses are removed. But YMMV. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-01 0:00 ` Ted Dennison @ 1999-07-02 0:00 ` czgrr 1999-07-02 0:00 ` Ted Dennison 0 siblings, 1 reply; 64+ messages in thread From: czgrr @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lg0sg$g8q$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Good point. But as a fellow "use-phobe", I think Neil would probably > prefer to put in "use type" statements to get access to the comparison > and mathematical operators that he will loose when the "use" clauses are > removed. "use type" - is that new in Ada95 then? Also, for us Ada83'ers, I suppose a "renames" declaration could be used instead of a "use" on the whole package. czgrr -- No email, please - reply to the newsgroup. My opinions are not necessarily those of my employer. Use any suggestions at your own risk. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` czgrr @ 1999-07-02 0:00 ` Ted Dennison 0 siblings, 0 replies; 64+ messages in thread From: Ted Dennison @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lhmps$3ll$1@nnrp1.deja.com>, czgrr <czgrr@my-deja.com> wrote: > In article <7lg0sg$g8q$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > Good point. But as a fellow "use-phobe", I think Neil would probably > > prefer to put in "use type" statements to get access to the comparison > > and mathematical operators that he will loose when the "use" clauses > are > > removed. > > "use type" - is that new in Ada95 then? Also, for us Ada83'ers, I > suppose a "renames" declaration could be used instead of a "use" on the > whole package. Exactly. "use type"'s purpose in life is pretty much to keep us use-phobes from having to put all those operator renames at the top of our package bodies. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-01 0:00 Elimination of "use" clauses Dr. Neil C. Audsley 1999-07-01 0:00 ` czgrr @ 1999-07-01 0:00 ` Samuel T. Harris 1999-07-01 0:00 ` Joe Wisniewski 1999-07-02 0:00 ` Robert Dewar 3 siblings, 0 replies; 64+ messages in thread From: Samuel T. Harris @ 1999-07-01 0:00 UTC (permalink / raw) "Dr. Neil C. Audsley" wrote: > > We have a lot of Ada source that "with"s and "use"s a lot of packages -- > to the extent that it is difficult and time-consuming to find out which > package a procedure is actually from. > Ideally, we would like to eliminate "use" clauses, necessitating the > replacement of each procedure call X by PackageName.X instead. > Is there a tool that does this? > Rational Apex has a "complete" facility which fully expands name of things, adds named notation. It can be used on already written constructs (your case) or on a partitial or even ambiguous call. If only partitial, it will fill in any missing parameters using named notation and use a [some_type_expression] as a filler for the missing actual parameters. If ambigous, it open a window with a list of possible candidates. You can "visit" each candidate to determine which one you need. The problem with this facility is that it used to work on a selection of code text but now only works on one statement at a time. Works good while supporting the writing of code but is very clumsy to use to retro-format existing code. As far as your general problem is concerned, if you audience reading the code can do it on-line, then a solution is to use one of the many tools which provide a similar "visit" function. Apex, Emacs with ada-tags, or ada2html from David Wheeler all come to mind. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-01 0:00 Elimination of "use" clauses Dr. Neil C. Audsley 1999-07-01 0:00 ` czgrr 1999-07-01 0:00 ` Samuel T. Harris @ 1999-07-01 0:00 ` Joe Wisniewski 1999-07-02 0:00 ` Robert Dewar 3 siblings, 0 replies; 64+ messages in thread From: Joe Wisniewski @ 1999-07-01 0:00 UTC (permalink / raw) I don't know of any tools out there that do this. Using ASIS, for detection of these occurrences would appear to be the way to go. Then obviously a source modification response. What platform? Which compiler and compiler vendor? If you don't find a tool this is something that I might like to take a crack at. Joe In article <377B5807.88B875E0@cs.york.ac.uk>, Neil.Audsley@cs.york.ac.uk wrote: > > We have a lot of Ada source that "with"s and "use"s a lot of packages -- > to the extent that it is difficult and time-consuming to find out which > package a procedure is actually from. > Ideally, we would like to eliminate "use" clauses, necessitating the > replacement of each procedure call X by PackageName.X instead. > Is there a tool that does this? > > -- > ======================================================================== = > Dr. Neil C. Audsley Email: neil@cs.york.ac.uk > Senior Research Fellow Phone: +44-1904-432787 > Department of Computer Science, Fax: +44-1904-432708 > University of York, > York. Y01 5DD, UK > Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-01 0:00 Elimination of "use" clauses Dr. Neil C. Audsley ` (2 preceding siblings ...) 1999-07-01 0:00 ` Joe Wisniewski @ 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Samuel T. Harris ` (2 more replies) 3 siblings, 3 replies; 64+ messages in thread From: Robert Dewar @ 1999-07-02 0:00 UTC (permalink / raw) In article <377B5807.88B875E0@cs.york.ac.uk>, Neil.Audsley@cs.york.ac.uk wrote: > > We have a lot of Ada source that "with"s and "use"s a lot of packages -- > to the extent that it is difficult and time-consuming to find out which > package a procedure is actually from. > Ideally, we would like to eliminate "use" clauses, necessitating the > replacement of each procedure call X by PackageName.X instead. > Is there a tool that does this? I don't know of a dotification tool, but it seems strange to claim that it is difficult and time-consuming to find out which package a procedure is from. That sounds like you are not using appropriate tools. Try using the EMACS interface to GNAT, and you can immediately go from any identifier to the declaration (and the proper package in which this declaration appears). This is actually much more useful in reading code, since you immediately find out not only what package the identifier is in, but you go to the declaration which shows you the details of what the identifier means. There are other tools that have this same capability. This seems pretty important functionality. There is also the gnatfind utility available with GNAT for providing this same kind of information in command line mode. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Robert Dewar @ 1999-07-02 0:00 ` Samuel T. Harris 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Ed Falis 2 siblings, 1 reply; 64+ messages in thread From: Samuel T. Harris @ 1999-07-02 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <377B5807.88B875E0@cs.york.ac.uk>, > Neil.Audsley@cs.york.ac.uk wrote: > > > > We have a lot of Ada source that "with"s and "use"s a lot of > packages -- > > to the extent that it is difficult and time-consuming to find > out which > > package a procedure is actually from. > > Ideally, we would like to eliminate "use" clauses, > necessitating the > > replacement of each procedure call X by PackageName.X instead. > > Is there a tool that does this? > > I don't know of a dotification tool, but it seems strange to > claim that it is difficult and time-consuming to find out > which package a procedure is from. That sounds like you are > not using appropriate tools. Try using the EMACS interface > to GNAT, and you can immediately go from any identifier to > the declaration (and the proper package in which this > declaration appears). This is actually much more useful in > reading code, since you immediately find out not only what > package the identifier is in, but you go to the declaration > which shows you the details of what the identifier means. > > There are other tools that have this same capability. This > seems pretty important functionality. There is also the gnatfind > utility available with GNAT for providing this same kind of > information in command line mode. There are times when no tool can be of any help. Doing work for NASA, we have customers which insist on reviewing code in their private work area. With no connectivity to our environment, they do not have access to our tools. Some of they even require hardcopy and reject any electronic form. So the problem is not entirely handled by good tools. Reasonable restrictions on the use clause are still appropriate to support such edge cases. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Samuel T. Harris @ 1999-07-02 0:00 ` Robert Dewar 1999-07-08 0:00 ` R. Tim Coslet [not found] ` <7ltl2q$mog$1@nnrp1.deja.com> 0 siblings, 2 replies; 64+ messages in thread From: Robert Dewar @ 1999-07-02 0:00 UTC (permalink / raw) In article <377CE178.6C15F543@hso.link.com>, "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > There are times when no tool can be of any help. > Doing work for NASA, we have customers which insist on > reviewing code in their private work area. With no > connectivity to our environment, they do not have > access to our tools. Some of they even require hardcopy > and reject any electronic form. Well there are people who refuse to drive automobiles, but that does not mean that we necessarily take into account those requirements in deciding how to layout our highways. You may also have customers who require Hungarian notation, but that does not mean it is a good thing. Yes, of course a dotifier (or for that matter a Hungarianizer) may be useful in bizarre environments > So the problem is not entirely handled by good tools. > Reasonable restrictions on the use clause are still > appropriate to support such edge cases. Well be careful. By supporting such edge cases, you may be making the programs harder to read and work with by everyone else. As I pointed out in a previous message, it is actually relatively unusual for people to fully qualify, that is especially true in these days of child packages. Do you really want to say: X := Ada.Numerics.Float_Random.Random (Gen); rather than X := Random (Gen); ? and that is by NO means the worst case. Well if you are really usephobic, or worse, live in an environment which mandates that use be disallowed (I have encountered such absurdities), then you end up doing a package renaming: X := NFR.Random (Gen); But this is *precisely* no help at all if you have decent tools, and creates useless noise. It does not tell you immediately where something is. The only purpose of the prefix NFR is to help you find the declaration of Random using decrepit tools. That to me is hard to justify. Once again, I think the critical factor is to consider what makes the code clearer. If you have people who insist on wasting their time by reading the code on paper, by all means get a dotifying tool and give them the entire long form above if that's what they want! Note that I am not arguing against qualification, just trying to stress that the decision to qualify should be based on factors other than the requirement of using decrepit tools. Of course there are those who have no choice. Fine, but that does not provide a source of inspiration on what ideal Ada style should be in an ideal environment. (actually for me, I agree with what someone wrote earlier, any Ada environment not providing this capability is broken and unusable as far as I am concerned). Even if you use FULL qualification, it is nowhere NEAR as convenient as going directly to the declaration with a decent tool. If you have not tried working in such an environment, give it a try, you may find it enlightening (and not have to reach so often for the baseball bat :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Robert Dewar @ 1999-07-08 0:00 ` R. Tim Coslet 1999-07-09 0:00 ` Robert Dewar [not found] ` <7ltl2q$mog$1@nnrp1.deja.com> 1 sibling, 1 reply; 64+ messages in thread From: R. Tim Coslet @ 1999-07-08 0:00 UTC (permalink / raw) Our coding standard prohibits "use", except for "use type" (because operator "renames" as we did in Ada83 get awful messy). Our coding standard USED to prohibit all use of "renames" (except for operators) for just the reason you give below: renaming packages to get short dot notation form simply obscures the code. They did finally loosen up on "renames" after seeing how a rename of an array reference or list reference inside a loop or subprogram works (and usually clues in the compiler to only do the index calculation ONCE instead of on every reference). Of course one has to realize that our entire coding standard was developed when our "environment" consisted of nothing but VAX LSE, an Ada83 compiler, and CCC. It is in review for potentially significant changes. Robert Dewar wrote: > In article <377CE178.6C15F543@hso.link.com>, > "Samuel T. Harris" <sam_harris@hso.link.com> wrote: > > and that is by NO means the worst case. Well if you are really > usephobic, or worse, live in an environment which mandates that > use be disallowed (I have encountered such absurdities), then > you end up doing a package renaming: > > X := NFR.Random (Gen); > > But this is *precisely* no help at all if you have decent > tools, and creates useless noise. It does not tell you > immediately where something is. The only purpose of the > prefix NFR is to help you find the declaration of Random > using decrepit tools. That to me is hard to justify. > > > (actually for me, I agree with what someone wrote earlier, any > Ada environment not providing this capability is broken and > unusable as far as I am concerned). Even if you use FULL > qualification, it is nowhere NEAR as convenient as going > directly to the declaration with a decent tool. If you have > not tried working in such an environment, give it a try, you > may find it enlightening (and not have to reach so often for > the baseball bat :-) > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-08 0:00 ` R. Tim Coslet @ 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` tmoran 0 siblings, 1 reply; 64+ messages in thread From: Robert Dewar @ 1999-07-09 0:00 UTC (permalink / raw) In article <3784F737.A04F466D@kaisere.com>, "R. Tim Coslet" <coslett@kaisere.com> wrote: > Our coding standard USED to prohibit all use of "renames" > (except for operators) for just the reason you give below: > renaming packages to get short dot notation form simply > obscures the code. A nice example of crippling the language in the name of controlling style! Renames is an absolutely critical feature of the language. It is important for abstraction purposes, and provides essential expressive power not at all easily replaced by any other means. For example if we have X : integer renames a(i,j).x1(k); it is really horrible to do Capture_I : constant integer := i; Capture_J : constant integer := j; Capture_K : constant integer := k; and then replace subsequent uses of X by A (Capture_I, Capture_J).x1(Capture_K); And of course I am assuming A and x1 are declared objects and not pointers, or things get even more ludicrous. > They did finally loosen up on "renames" after seeing how a > rename of an array reference or list reference inside a loop > or subprogram works (and usually clues in the compiler to only > do the index calculation ONCE instead of on every reference). A decent compiler should do this automatically in almost all cases without the need for renames, but in any case this is a lousy reason for modifying the standards (ok, we will write what we think is kludgy code because our compiler generates better code if we do). The proper reason for loosening up on this rule is that there is no point in removing critical features of the language without very good reason. Worrying about misuse in package namings is not a "very good reason". Almost all rules on Ada style that prohibit the use of a feature entirely are misguided. I say almost all, because there are definite examples, which are not so much style rules, as usage rules, e.g. don't use dynamic allocation in safety critical programs. They typically correspond to the use of pragma Restrictions. Going back to the use clause case, if you prohibit use completely, and do not allow package renamings, then you provoke another common disease, short cryptic package names. And please note that all this gets *MUCH* worse with child packages in Ada 95. No doubt some brilliant manager will prohibit the use of child packages because it leads to unwieldy names :-) > Of course one has to realize that our entire coding standard > was developed when our "environment" consisted of nothing but > VAX LSE, an Ada83 compiler, and CCC. It is in review for > potentially significant changes. It is definitely reasonable to take environment and tools into effect when designing coding standards. The package renaming for example is not unreasonable if you really are confined to reading all code on paper. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Robert Dewar @ 1999-07-09 0:00 ` tmoran 0 siblings, 0 replies; 64+ messages in thread From: tmoran @ 1999-07-09 0:00 UTC (permalink / raw) > No doubt some brilliant manager will prohibit the use of > child packages because it leads to unwieldy names :-) (Quite) some years ago I did a COBOL project for Intel. The manager wanted all paragraph names to be sequential numbers. #.# ^ permalink raw reply [flat|nested] 64+ messages in thread
[parent not found: <7ltl2q$mog$1@nnrp1.deja.com>]
* Re: Elimination of "use" clauses [not found] ` <7ltl2q$mog$1@nnrp1.deja.com> @ 1999-07-08 0:00 ` Michael F. Yoder 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` Richard D Riehle 0 siblings, 2 replies; 64+ messages in thread From: Michael F. Yoder @ 1999-07-08 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <7ljbsu$ni7$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> wrote: > > > and that is by NO means the worst case. Well if you are really > > usephobic, or worse, live in an environment which mandates that > > use be disallowed (I have encountered such absurdities), then > > you end up doing a package renaming: > > > > X := NFR.Random (Gen); > > Interesting strawman. But the enviroments I have worked in tend to > highly discourage "renames" as well. So instead you are "stuck" using > full dot notation. Not a strawman. The best ways of dealing with use clauses are what I call "Tony Tye" methods (since he devised the first one I used) and make package renamings a staple. The basis of these methods is to have a simple package renaming, at the top of a unit, for every "withed" package; this renaming provides an abbreviated name for that package within the unit. If you like acronyms you might use ASU for Ada.Strings.Unbounded and ASWU for Ada.Strings.Wide_Unbounded. I'd more likely use, e.g., Unb and WUnb. It is helpful but not necessary to keep these abbreviations consistent across units. Most (or all) identifiers denoting entities in the "withed" packages are then prefixed by an abbreviated name and a dot. A strict "Tony Tye" method would forbid 'use' and 'use type' clauses entirely. A loose one would allow all 'use type' clauses, and also allow 'use' for all predefined packages and at most one non-predefined package. The point to the "at most one" rule is that it enables you to (usually) know at a glance where any identifier is declared: if X isn't from any surrounding scope, and you know the predefined packages well enough to tell X isn't from one of them, it must be in the single special used package. My personal preference is to be fairly free about 'use type' (but to drive it into the narrowest scope possible) and to otherwise lean towards no use clauses at all. I'll admit I sometimes allow myself two used packages if one is Ada.Text_IO. This is better than using fancy tools because even if the tool use is as simple as double-clicking on the identifier, that's more distracting than having the information immediately evident. It requires no conscious thought or finger movement to realize that 'Unb.Insert' comes from the unbounded strings package. "Use-phobia" of this sort usually aids code reading, whether the code is hardcopy or not. ---- Michael Yoder ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-08 0:00 ` Michael F. Yoder @ 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` Dale Stanbrough ` (2 more replies) 1999-07-09 0:00 ` Richard D Riehle 1 sibling, 3 replies; 64+ messages in thread From: Robert Dewar @ 1999-07-09 0:00 UTC (permalink / raw) In article <3784DC54.6463EDCA@decada.zko.dec.com>, "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote: > It requires no > conscious thought or finger movement to realize that > 'Unb.Insert' comes > from the unbounded strings package. Or perhaps unbounded trees, or perhaps the Universal_National_Boundaries package? I personally dislike these kind of package abbreviations. They are fine for people who know the code well, but they probably know where stuff is anyway. Otherwise you constantly have to be searching back to find out what peculiar abbreviations have been used. A good rule, one that is required in many Ada coding standards, is no abbreviations. I see no reason why this rule should not apply to renamings of packages, but in my experience, people are so desparate to have very short names when they have to type them all over the place, that they choose very short cryptic abbreviations (I consider incidentally that Unb for Ada.Strings.Unbounded is in that category). This is a matter of taste of course, and there are many styles, but this is the one I like least. I would prefer to see honest full qualification, rather than cryptic abbreviations. And as for USE TYPE, anyone who thinks it is acceptable to say X := Special_Operation_Types."+"(A,B); does not have my sympath, and replacing this with X := SOT."+"(A,B); is not helpful. Yes, of course you can use renamings, but what possible value is this. If you see: X := A + B; then it is *definitely* useful to be able to click on the "+" to quickly check if this plus is other than a standard one (perhaps a really nice tool would paint such operators in a different color). But looking at a bunch of renaming operations for "+" at the front of the package and then trying to figure out if one of them applies, given the types of A and B is no fun. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Robert Dewar @ 1999-07-09 0:00 ` Dale Stanbrough 1999-07-12 0:00 ` Robert Dewar 1999-07-09 0:00 ` Michael F. Yoder 1999-07-10 0:00 ` Simon Wright 2 siblings, 1 reply; 64+ messages in thread From: Dale Stanbrough @ 1999-07-09 0:00 UTC (permalink / raw) Robert Dewar wrote: This is a matter of taste of course, and there are many styles, but this is the one I like least. I would prefer to see honest full qualification, rather than cryptic abbreviations. I have a package that only withs Ada.Text_IO, and the package defines it's own put procedures. Instead of Ada.Text_IO.Put (...) (or Text_IO.Put) I have a renames to ATIO which IMHO is readable (but mainly because there is only one with). I would think that the Ada heirachy could be renamed to shorter names if... there are very few withs in the unit the contractions are standardized (first letter of each word in a package name. e.g. Ada.Strings.Unbounded => ASU, Ada.Stream_IO => ASIO etc) the renamings only occur within a unit, and not at the library level without causing too much distress. Dale ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Dale Stanbrough @ 1999-07-12 0:00 ` Robert Dewar 1999-07-12 0:00 ` Ted Dennison 0 siblings, 1 reply; 64+ messages in thread From: Robert Dewar @ 1999-07-12 0:00 UTC (permalink / raw) In article <dale-0907991223380001@dale.cs.rmit.edu.au>, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > I would think that the Ada heirachy could be renamed to > shorter names if... My preferred approach would be to forbid any user packages from duplicating the names used in the RM in Annex A and other standard packages, unless there is a very definite methodological reason for the duplication (e.g. defining a Put procedure for additional types). If this is followed, then since all these names are familiar to Ada programmers, I see no reason to use such package abbreviations for these names. On the contrary, such abbreviations may indeed imply that you are NOT using the standard routines. If you must prefix the routines, I will say again, that I prefer Ada.Text_IO.Put to ATIO.Put This is certainly a matter of taste, but the objection to abbreviations is a pretty common one, and as I said before, many style guides discourage or forbid abbreviations (what has AQ&S to say on the abbreviation issue). Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-12 0:00 ` Robert Dewar @ 1999-07-12 0:00 ` Ted Dennison 0 siblings, 0 replies; 64+ messages in thread From: Ted Dennison @ 1999-07-12 0:00 UTC (permalink / raw) In article <7mdml7$vo4$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > My preferred approach would be to forbid any user packages > from duplicating the names used in the RM in Annex A and > other standard packages, unless there is a very definite > methodological reason for the duplication (e.g. defining > a Put procedure for additional types). That's a pretty hefty set of useful names you are putting off-limits! For instance: "Move", "Index", "Count", "Insert", "Delete" (Ada.Strings.Fixed) "Split" (Ada.Calendar) "Read", "Write" (Ada.Storage_IO, Ada.Streams) "Create", "Reset", "Name" (Ada.Text_IO) "Initialize", "Adjust" (Ada.Finalization) "Size" (Ada.Direct_IO) Looking over this list, its interesting how much more sense each makes at first glance when given the context of its package name... -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` Dale Stanbrough @ 1999-07-09 0:00 ` Michael F. Yoder 1999-07-14 0:00 ` Tucker Taft 1999-07-10 0:00 ` Simon Wright 2 siblings, 1 reply; 64+ messages in thread From: Michael F. Yoder @ 1999-07-09 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <3784DC54.6463EDCA@decada.zko.dec.com>, > "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote: > > It requires no > > conscious thought or finger movement to realize that > > 'Unb.Insert' comes > > from the unbounded strings package. > > Or perhaps unbounded trees, or perhaps the > Universal_National_Boundaries package? This is not a reasonable objection, because it assumes the worst possible usage of the method. (This *is* a strawman argument.) If both unbounded strings and unbounded trees were "withed" units, the abbreviations would be something like UStr and UTree. And Universal_National_Boundaries would be abbreviated UNB, not Unb, if you chose to allow acronyms. (Using case to improve readability is desirable even in a case-insensitive language.) > I personally dislike these kind of package abbreviations. They > are fine for people who know the code well, but they probably > know where stuff is anyway. > > Otherwise you constantly have to be searching back to find out > what peculiar abbreviations have been used. This simply isn't so in my experience. It takes at most one or two readings of the renamings to internalize them. If you are aware of the method, you treat the renamings as an extension of the context clause; and of course you should habitually read the context clause of a unit before reading the unit. Even if you aren't aware of the method, you should read the global declarations at the top of a unit body. It might be useful to this thread to give some history of the method I discussed. It was devised precisely because there was general disgruntlement in our project about unreadability of code induced by overly generous usage of use clauses. On that project, the method simply solved the problem. Ever since then, I've not seen any case where introducing such methods (or moving closer to them) hasn't improved code readability even months or years after such changes. To me, the superiority of the method is an observed empirical fact; nor is it a matter of what I am used to, since it wasn't the first method I used. I would certainly be willing to risk large amounts of money on the method's being better than most others. > [material about operators omitted] Operators I prefer to treat as a separate question, because I believe the best solution is different for operators and identifiers. I have a personal preference, but I don't feel it is clearly superior to other methods. With identifiers my experience has led me to a strong preference. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Michael F. Yoder @ 1999-07-14 0:00 ` Tucker Taft 0 siblings, 0 replies; 64+ messages in thread From: Tucker Taft @ 1999-07-14 0:00 UTC (permalink / raw) Michael F. Yoder wrote: > ... > This simply isn't so in my experience. It takes at most one or two > readings of the renamings to internalize them. If you are aware of the > method, you treat the renamings as an extension of the context clause; > and of course you should habitually read the context clause of a unit > before reading the unit. Even if you aren't aware of the method, you > should read the global declarations at the top of a unit body. For what it is worth, we have used the package renaming approach in our all of our tools since 1980. Probably about a million lines of code all told, counting the AIE and derivatives thereof. We certainly tried to have project-wide agreement on the official short name for every package. Even when there were local variations, it was still quite manageable. (In Ada 95 you have an option of actually putting the official short names into the library using library-unit renames, though I'm not sure whether it is a good idea to take advantage of that for this purpose.) In any case, we quite rapidly reached the point that we all knew the short names by heart, and it significantly improved the signal-to-noise ratio compared to using full package names everywhere, and minimized the mystery associated with using multiple use clauses. Of course, as in all of these things, your mileage may vary. But we at least have gotten very good mileage out of the package rename approach, and I would suggest other shops give it a try to see whether it solves their problems. Combined with "use type" for operators, it has worked even better for us in Ada 95. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` Dale Stanbrough 1999-07-09 0:00 ` Michael F. Yoder @ 1999-07-10 0:00 ` Simon Wright 1999-07-12 0:00 ` Robert Dewar 2 siblings, 1 reply; 64+ messages in thread From: Simon Wright @ 1999-07-10 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > I personally dislike these kind of package abbreviations. They > are fine for people who know the code well, but they probably > know where stuff is anyway. I first came across consistent renamings like this in the GNAT sources: package body System.Pool_Global is package SSE renames System.Storage_Elements; and thought it a pretty cool notion. is ACT changing its style, then? (your privilege, of course!) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-10 0:00 ` Simon Wright @ 1999-07-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 64+ messages in thread From: Robert Dewar @ 1999-07-12 0:00 UTC (permalink / raw) In article <x7vso6xvsbw.fsf@pogner.moho>, Simon Wright <simon@pogner.demon.co.uk> wrote: > I first came across consistent renamings like this in the GNAT > sources: > > package body System.Pool_Global is > > package SSE renames System.Storage_Elements; > > and thought it a pretty cool notion. is ACT changing its style, then? > (your privilege, of course!) First: ACT /= Dewar. Just because I like something does not mean my preference is what we do (I prefer all upper case identifiers, but everyone else preferred mixed case, so that's what we use, and now I am used enough to that and it is OK). As for the specs, as you know, we have a convention of not allowing use clauses in internal library packages that is inspired by the rtsfind restrictions. General GNAT style is to prefer general use of use clauses. Most certainly we would not get into prefixing uses of system.storage_units if it were not for the rtsfind restrictions (se the GNAT sources if you want to find out more about that). But anyway, if you think this notation is cool, fine .. I find it OK for very small units like these, but it is not something I would use in larger units. For example, if you look at g-spipat.adb, which I *did* write, it is 6000 lines long (the SPITBOL pattern matching stuff is complex -- half is comments but half is real code), and there is not one use of package renaming, but there are use clauses, and this represents my preferred style. Of course we DO have tools that allow us to immediately locate a specific reference, and we use naming conventions that minimize confusion. One of the things I often see happening in big projects is that there is simply no management control over the global name space, so all kinds of different styles of naming coexist in a program. I find that *really* horrible, and it does for sure make it harder to figure out where things are. In GNAT, if you see a name like Expand_N_Task_Body, you know it must be in exp_ch9.adb, since it is clearly an expansion routine, and you know that tasks are in chapter 9. The use of Exp_Ch9.Expand_N_Task_Body would be entirely gratuitous for anyone with the slightest familiarity with these sources (and indeed annoying). So part of the issue here is definitely control of name spaces. I certainly agree that explicit naming may be more useful when you have lost control of the name space. One additional point, I really object to the use of explicit qualification for dynamically overloaded primitive operations of tagged types. Pointing back to the parent unit, which is where the declaration is, but most certainly is NOT where the executable code can be found, can often be quite confusing. If you see Module_Methods.List_Module; it is an invitation to go to the body of Module_Methods to find the code being executed, and of course in some sense the whole idea of object oriented programming that makes use of dyamic dispatching is that you CANNOT tell at the source level where the code for some operation is located. Yes, it can correctly point to the declaration, but far too often the declarations are not sufficiently commented, and the feeling that the body is a legitimate place to go to look to see how something works is a common one, and one that can not be avoided with a lot of inadequately commented code. There, that should start another interesting subthread in the old use discussion (incidentally, so far this thread has not generated even one tiny small point that is new, but it seems to be something that people like to talk about :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-08 0:00 ` Michael F. Yoder 1999-07-09 0:00 ` Robert Dewar @ 1999-07-09 0:00 ` Richard D Riehle 1999-07-09 0:00 ` Michael F. Yoder 1999-07-09 0:00 ` Marin David Condic 1 sibling, 2 replies; 64+ messages in thread From: Richard D Riehle @ 1999-07-09 0:00 UTC (permalink / raw) In article <3784DC54.6463EDCA@decada.zko.dec.com>, "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote: >Not a strawman. The best ways of dealing with use clauses are what I >call "Tony Tye" methods (since he devised the first one I used) and make >package renamings a staple. This is a widely used technique. It does not completely solve the use clause question. What problem are we trying to solve? Ada is unique in its separation of scope from visibility. In any other language we would not even be discussing this issue. As noted earlier, the rules of Ada are analogous to default insulation on every entity. With most languages we have code that is the equivalent of bare wires running all over the place. Cavalier coding of the use clause is the same as removing all that nice insulation. Ada permits us to remove the insulation at appropriate places. We would never expect a consumer to go around scraping insulation from electrical wires in the home. We should not expect clients of packages to do the same. Instead, we should carefully expose, in our package design, those places where entities can safely connect with each other. This is a key difference between engineering and programming. The use clause, when invoked willy-nilly, exposes too much of the bare wire. The use type is not much better, but one can see its usefulness in teaching environments. At the same time, excessive paranoia over the use clause is usually unwarranted. In my earlier posting on this topic I said that the designer, not the client/consumer, should be responsible for deciding what should be exposed and what should be hidden. That is the purpose of creating restricted operator packages that can be referenced via the use clause. If a package is properly designed, the use clause applied to the restricted set of operators will be both easier to "use" and safer than many of the alternatives. We as designers need to take responsibility for this. Admittedly, most Ada packages in the existing software repositories have fallen short in addressing this issue. We can correct this in future designs. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Richard D Riehle @ 1999-07-09 0:00 ` Michael F. Yoder 1999-07-09 0:00 ` Marin David Condic 1 sibling, 0 replies; 64+ messages in thread From: Michael F. Yoder @ 1999-07-09 0:00 UTC (permalink / raw) Richard D Riehle wrote: > > In article <3784DC54.6463EDCA@decada.zko.dec.com>, > "Michael F. Yoder" <yoder@decada.zko.dec.com> wrote: > > >Not a strawman. The best ways of dealing with use clauses are what I > >call "Tony Tye" methods (since he devised the first one I used) and make > >package renamings a staple. > > This is a widely used technique. It does not completely solve the > use clause question. What problem are we trying to solve? Perhaps there is a difference in perception, or in experience, here. In my experience, the described method does in fact completely solve the problem of use clauses contributing to code obfuscation (for identifiers, and for all practical purposes). It does not, in my opinion, necessarily provide the best solution for operators. I'd prefer to have the two questions separated, and I have no strong opinions to contribute to the discussion about operators. On the project Tony Tye led, complaints about use clauses simply didn't occur after the method was introduced. I don't know of any instance in which introducing such a method led to a perceived reduction in readability, but perhaps those participating in this discussion can contribute some. :-) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-09 0:00 ` Richard D Riehle 1999-07-09 0:00 ` Michael F. Yoder @ 1999-07-09 0:00 ` Marin David Condic 1 sibling, 0 replies; 64+ messages in thread From: Marin David Condic @ 1999-07-09 0:00 UTC (permalink / raw) Richard D Riehle wrote: > > Ada permits us to remove the insulation at appropriate places. We would > never expect a consumer to go around scraping insulation from electrical > wires in the home. We should not expect clients of packages to do the > same. Instead, we should carefully expose, in our package design, those > places where entities can safely connect with each other. This is a key > difference between engineering and programming. > I think I can agree that package designers can/should help make decisions about what should be directly visible, via some version of the _Ops package, but don't you think that a lot of visibility issues are going to depend on the caller? I mean, when I buy a 100 feet of wire at The Home Depot, I expect the *default* to be that it is insulated so that I don't string it through my attic and produce hazards where I least expect it. But with a trusty pair of wire dykes I expect to strip & connect where my application demands. I personally like to limit the "use" clause to the smallest scope possible - If I'm using Ada.Strings.Unbounded somewhere in a package, I may use explicit dotted notation on the parameters of the subprograms, but within the subprogram itself, apply the "use" clause to eliminate the clutter. The caller of my package then knows where to find the data types for the parameters, but within the package we kind of assume that someone will recognize "Move" and "To_String" as being operations from A.S.U. But it was *my* decision about what is clear and what may be obfuscated within the context of my application. > The use clause, when invoked willy-nilly, exposes too much of the > bare wire. The use type is not much better, but one can see its > usefulness in teaching environments. At the same time, excessive > paranoia over the use clause is usually unwarranted. > I think it tends to be a tempest in a teapot. In practice, I think clarity is more a result of the talent of the programmer rather than the language features. Someone who thinks, speaks and writes clearly is likely to produce code that communicates its intentions clearly with or without the use clause. I think the advantage of the use clause is more one of protecting the namespace than one of clarity/obfuscation. If the given caller has no ambiguities or collisions with the names of the withed package, the use clause is probably not going to hurt the clarity much. If there are collisions, then avoid the use clause. (Except for infix operators! There's nothing uglier than seeing 'My_Package."<" (L, R)' ;-) In general, eschew obfuscation. :-) MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Samuel T. Harris @ 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Robert Dewar ` (2 more replies) 1999-07-02 0:00 ` Ed Falis 2 siblings, 3 replies; 64+ messages in thread From: Ted Dennison @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lh74s$v36$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> wrote: > In article <377B5807.88B875E0@cs.york.ac.uk>, > Neil.Audsley@cs.york.ac.uk wrote: > > > > We have a lot of Ada source that "with"s and "use"s a lot of > packages -- > > to the extent that it is difficult and time-consuming to find > out which > > package a procedure is actually from. > I don't know of a dotification tool, but it seems strange to > claim that it is difficult and time-consuming to find out > which package a procedure is from. That sounds like you are > not using appropriate tools. Try using the EMACS interface While I appreciate the fact that *some* compiler systems have facilites to help decipher stuff like this under *certian* circumstances, I am not persuaded that obtuse source code is just a "tool problem". If I have to use specialized tools to figure out what someone's source code is doing, the tool that springs most readily to mind is a baseball bat... -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Ted Dennison @ 1999-07-02 0:00 ` Robert Dewar [not found] ` <7ltus1$ah1@dfw-ixnews19.ix.netcom.com> 1999-07-02 0:00 ` Stephen Leake 1999-07-02 0:00 ` Ed Falis 2 siblings, 1 reply; 64+ messages in thread From: Robert Dewar @ 1999-07-02 0:00 UTC (permalink / raw) In article <7ligdq$c8q$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > While I appreciate the fact that *some* compiler systems have > facilites to help decipher stuff like this under *certian* > circumstances, I am not > persuaded that obtuse source code is just a "tool problem". Actually there are many of us who feel that using dotted notation all over the place actually obscures the code, especially once you know it fairly well. I personally find the dots annoying -- why? well you have far more text which is conveying no more semantic information. I find this only one step removed from the use of Hungarian notations. Of course I realize other people differ, but there are two kinds of use phobes: a) people who really prefer the dots b) people who put up with the dots because it is the only reasonable way they have of finding things Please understand that my message is addressed exclusively to the second group :-) > If I have to use specialized tools to figure out what > someone's source code is doing, the tool that springs most > readily to mind is a baseball bat... In a decent Ada environment, this should not be considered a specialized tool, but rather a necessity. Note that even most use phobes can't stand to dot operator names, so at the very least you need the tool that allows you to click on an operator name and find out where the operator is defined. Note that many people can't stand to put the full package names on the dots anyway, so you get notations like CT.List instead of Compressed_Tree.List Now you have to first find CT to know where things are. How will you find CT? Well you use some tool. Perhaps you use some decrepit tool like the search of an editor. But it would be better to use the click and find procedure even for CT if you have decent tools. If you have these decent tools, then you might as well click on List and get where you really want to go. I am sorry Ted has to deal with such a decrepit environment that the challenge of finding out where a variable is defined makes him reach for the baseball bat, but I am not at all sure that we should condition our style on the limitations of such environments. The decision to use or not use USE clauses should be based on what makes the code clearer, not on entirely unreasonable and unnecessary limitations of tool sets. Probably the majority of Ada programmers fall between the ALWAYS and NEVER use groups, and instead take a reasonable approach of using USE where appropriate, and not using it where it is not helpful. Robert Dewar Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
[parent not found: <7ltus1$ah1@dfw-ixnews19.ix.netcom.com>]
* Re: Elimination of "use" clauses [not found] ` <7ltus1$ah1@dfw-ixnews19.ix.netcom.com> @ 1999-07-13 0:00 ` Robert A Duff 1999-07-18 0:00 ` Richard D Riehle 0 siblings, 1 reply; 64+ messages in thread From: Robert A Duff @ 1999-07-13 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > package Sweet_Tooth is > > type Frozen_Dessert is private; > type Lollipop is (OrangeIce, Fudgecicle, Chocolate_Cream); > > Procedure Create (F : in out Frozen_Dessert); > -- more operations > -- declare an Operators only package > package Ops is > function "=" (L, R : Lollipop) return Boolean > renames Sweet_Tooth."="; > function ">" (L, R : Lollipop) return Boolean > renames Sweet_Tooth.">"; I used to like this idea, but I've seen nasty bugs caused by it. Imagine if that last ">" were replaced with "=" due to a cut-and-paste error. It's hard to notice such a bug by reading the code, because as soon as you see "package Ops is" followed by "function ">"", you already know (or *think* you know) what comes next, so you don't read it carefully. And when you're reading someplace else that calls "<", you obviously think it's calling something called "<". The "use type" clause is safer. > This package has the advantage of exporting, through a use clause, only > the operators you want unless you decide to make others explicitly > visible. The client of the package has an easy way to achieve the > necessary visibility. It is a better option than use type because it > only makes visible a restricted set of operators. Good point. I wouldn't mind having a concise way of saying (eg) "T is an integer type with just "+" and "-" operators. But I still prefer "use type" to "package Ops". >... Also, it allows one > to design new behavior for some operators while implementing others > through a simple renames clause. It seems like a dangerous idea to use anything *but* a renaming, if the operator in question is predefined. I mean, if Sweet_Tooth."=" and Sweet_Tooth.Ops."=" do two different things, you're asking for trouble. Maybe I misunderstood what you mean, here. >... With Ada 95 you could create a child package for Sweet_Tooth.Ops > to keep it extensible. I don't understand that point. > Ada's use clause, like the #include of the C family of languages, > is somewhat analogous to wiring your home with uninsulated cable. That analogy is a bit overblown! If you want to insulate something, put it in a package body where it belongs. And surely "use" is not in the same category as "#include". - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-13 0:00 ` Robert A Duff @ 1999-07-18 0:00 ` Richard D Riehle 1999-07-18 0:00 ` Dale Stanbrough ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Richard D Riehle @ 1999-07-18 0:00 UTC (permalink / raw) I always enjoy the thoughtful responses posted here by Dr. Duff. In article <wccr9mc5y47.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: in response to my advocacy of a nested or child Ops package (see the code moved to the end of this posting) >I used to like this idea, but I've seen nasty bugs caused by it. >Imagine if that last ">" were replaced with "=" due to a cut-and-paste >error. It's hard to notice such a bug by reading the code, because as >soon as you see "package Ops is" followed by "function ">"", you already >know (or *think* you know) what comes next, so you don't read it >carefully. And when you're reading someplace else that calls "<", you >obviously think it's calling something called "<". Cut and paste errors are one of the inherent problems with renaming, especially a liberal model for renaming. I agree that one must be careful about such things. More frequently, I have seen people use ">" when then intended "<". This error is still possible with "use type". If one only exports the "<", the chance of making a mistake of ">" is reduced. >The "use type" clause is safer. Respectfully disagree. The use type clause exports visibility for every operator on a type. Now, if use type allowed a list of the operators to be restricted ... For example, use type X.T ("=", "<", "/"); one would be able to designate exactly which operators were appropriate to the use of the type. This is analogous to the "export" directive found in some other languages. >> This package has the advantage of exporting, through a use clause, only >> the operators you want unless you decide to make others explicitly >> visible. The client of the package has an easy way to achieve the >> necessary visibility. It is a better option than use type because it >> only makes visible a restricted set of operators. > >Good point. I wouldn't mind having a concise way of saying (eg) "T is >an integer type with just "+" and "-" operators. But I still prefer >"use type" to "package Ops". We agree up to a certain point. Explicit export directives would solve the problem, but that is not currently part of Ada. Again, "use type" is too broad, I think. >>... Also, it allows one >> to design new behavior for some operators while implementing others >> through a simple renames clause. > >It seems like a dangerous idea to use anything *but* a renaming, if the >operator in question is predefined. I mean, if Sweet_Tooth."=" and >Sweet_Tooth.Ops."=" do two different things, you're asking for trouble. >Maybe I misunderstood what you mean, here. The example that comes to mind is the division operator on a floating point value. Instead of implementing it via a renames in package Sweet_Tooth.Ops, I might want to design my own "/" which does additional checking of the values, raises some specialized exception, takes into account a set of tolerable ranges instead of behaving exactly as defined in the language or numerics annex. The same could be true of other arithmetic operators. Also, the "=" operator on a floating point might be designed to greater tolerances than predefined by the language. >>... With Ada 95 you could create a child package for Sweet_Tooth.Ops >> to keep it extensible. >I don't understand that point. This simply means that Sweet_Tooth.Ops could be a child package of Sweet_Tooth instead of a nested package. In that case, it is extensible with new operators as necessary. >> Ada's use clause, like the #include of the C family of languages, >> is somewhat analogous to wiring your home with uninsulated cable. > >That analogy is a bit overblown! If you want to insulate something, put >it in a package body where it belongs. And surely "use" is not in the >same category as "#include". Analogies always have their flaws. The suggestion of putting the entity into the package body is, I agree, the ideal. If this were Modula-3, that would solve the problem quite nicely. Since Ada is not designed to explicitly support opaque types, one must often use indirection to support this notion. When a "with" and "use" are used together, it is very much like removing the insulation. Although it is not quite as dangerous as the C++ #include, it is very close to it. To be sure, we still have all the issues of type conformity, semantic legalities, etc., but we also have the problem of excessive visibility. One of Ada's most positive strengths, as a software engineering language, is the separation of scope and visibility. Perhaps what is needed, in the next revision, is some additional syntax for making this feature even stronger. Maybe we really do need some kind of "export" feature so the designer of a package can be explicit about what should be allowed and what should not be. Meanwhile, the nested or child Ops package, properly designed, provides that level of control. I think it does so better than the "use type" since it restricts the set of operators available via any use clause. Richard Riehle richard@adaworks.com http://www.adaworks.com -- =========== Original Code for this Discussion ================ >Richard D Riehle <laoXhai@ix.netcom.com> writes: > >> package Sweet_Tooth is >> >> type Frozen_Dessert is private; >> type Lollipop is (OrangeIce, Fudgecicle, Chocolate_Cream); >> >> Procedure Create (F : in out Frozen_Dessert); >> -- more operations >> -- declare an Operators only package >> package Ops is >> function "=" (L, R : Lollipop) return Boolean >> renames Sweet_Tooth."="; >> function ">" (L, R : Lollipop) return Boolean >> renames Sweet_Tooth.">"; >> end Ops; ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` Richard D Riehle @ 1999-07-18 0:00 ` Dale Stanbrough 1999-07-20 0:00 ` Richard D Riehle 1999-07-20 0:00 ` David Kristola 1999-07-18 0:00 ` jerry 1999-07-19 0:00 ` Elimination of "use" clauses Ted Dennison 2 siblings, 2 replies; 64+ messages in thread From: Dale Stanbrough @ 1999-07-18 0:00 UTC (permalink / raw) Richard D Riehle wrote: " >Good point. I wouldn't mind having a concise way of saying (eg) "T is >an integer type with just "+" and "-" operators. But I still prefer >"use type" to "package Ops". We agree up to a certain point. Explicit export directives would solve the problem, but that is not currently part of Ada. Again, "use type" is too broad, I think. " Export directives -could- do it (and it is not a bad idea at all), but we shouldn't forget that Ada already has the ability to export -just- the operators we want, and it's called using a private type and only advertising the appropriate operations. However this has the disadvantage that you can't use the private type in all the places that you might want to use an integer type. Dale ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` Dale Stanbrough @ 1999-07-20 0:00 ` Richard D Riehle 1999-07-19 0:00 ` Brian Rogoff 1999-07-23 0:00 ` Tucker Taft 1999-07-20 0:00 ` David Kristola 1 sibling, 2 replies; 64+ messages in thread From: Richard D Riehle @ 1999-07-20 0:00 UTC (permalink / raw) In article <dale-1807991510420001@192.168.0.2>, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: >Export directives -could- do it (and it is not a bad idea at all), >but we shouldn't forget that Ada already has the ability to export >-just- the operators we want, and it's called using a private type >and only advertising the appropriate operations. I fully agree that the private type is underused for this purpose. However, you will need to declare the arithmetic and logical operators for a private type. This is the ideal place for using a nested Ops package to restrict the set of operators to exactly those you want available in your design. package P is type T is private; -- operations on T package Ops is function ">" (L, R : T) return Boolean; function "+" (L, R : T) return T; end Ops; end P; Now, use P.Ops makes sense and exports only the operators the designer feels are appropriate but still restricts them to an Ops package. Of course, if they were not in the nested Ops package, one could still invoke the "use type" clause. In the end, I think it it will be a matter of preference rather than a matter of which is better. >However this has the disadvantage that you can't use the private >type in all the places that you might want to use an integer type. That is exactly the point. We need to explicitly define the operators for the private type so it is not exactly like a free integer. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Richard D Riehle @ 1999-07-19 0:00 ` Brian Rogoff 1999-07-20 0:00 ` Robert Dewar 1999-07-23 0:00 ` Tucker Taft 1 sibling, 1 reply; 64+ messages in thread From: Brian Rogoff @ 1999-07-19 0:00 UTC (permalink / raw) On Tue, 20 Jul 1999, Richard D Riehle wrote: > In article <dale-1807991510420001@192.168.0.2>, > dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > > >Export directives -could- do it (and it is not a bad idea at all), > >but we shouldn't forget that Ada already has the ability to export > >-just- the operators we want, and it's called using a private type > >and only advertising the appropriate operations. > > I fully agree that the private type is underused for this purpose. > However, you will need to declare the arithmetic and logical > operators for a private type. This is the ideal place for using > a nested Ops package to restrict the set of operators to exactly > those you want available in your design. If you don't mind making the client refuse to look at things he doesn't want to see, rather than making the provider hide what he doesn't want to show, generic signature packages could also be used in these situations. I still really dislike "use type". -- Brian ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-19 0:00 ` Brian Rogoff @ 1999-07-20 0:00 ` Robert Dewar 1999-07-20 0:00 ` Brian Rogoff 1999-07-21 0:00 ` Robert A Duff 0 siblings, 2 replies; 64+ messages in thread From: Robert Dewar @ 1999-07-20 0:00 UTC (permalink / raw) In article > I still really dislike "use type". Why? You have not clearly stated a reason for this dislike! And I certainly have not seen any satisfactory substitute proposed! Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Robert Dewar @ 1999-07-20 0:00 ` Brian Rogoff 1999-07-21 0:00 ` Robert Dewar 1999-07-21 0:00 ` Ted Dennison 1999-07-21 0:00 ` Robert A Duff 1 sibling, 2 replies; 64+ messages in thread From: Brian Rogoff @ 1999-07-20 0:00 UTC (permalink / raw) On Tue, 20 Jul 1999, Robert Dewar wrote: > In article > I still really dislike "use type". > > Why? You have not clearly stated a reason for this dislike! They are unnecessary, add no expressive power to Ada, and will look really ugly if (when?) "with type" is added to fix the mutually recursive package spec problem. I find the idea of "special casing" the operators inelegant; if anything I'd prefer that operators and functions were more alike and that one could define new infix operators. > And I certainly have not seen any satisfactory substitute > proposed! Regular "use" clauses, inside of declarative regions to limit their scope if one is worried about not being able to tell where a definition comes from. I am not a use-phobe, though I understand that one should be careful with use clauses (and aliasing, and overloading, and access types, etc.) -- Brian ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Brian Rogoff @ 1999-07-21 0:00 ` Robert Dewar 1999-07-21 0:00 ` Brian Rogoff 1999-07-21 0:00 ` Ted Dennison 1 sibling, 1 reply; 64+ messages in thread From: Robert Dewar @ 1999-07-21 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9907201840120.500-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > Regular "use" clauses, inside of declarative regions to limit their scope > if one is worried about not being able to tell where a definition comes > from. I am not a use-phobe, though I understand that one should be careful > with use clauses (and aliasing, and overloading, and access types, etc.) OK, that's reasonable. But you have to realize that use type was introduced into the language SPECIFICALLY for people who reject the above solution. Since there are MANY such people, there was a strong constituency for this feature. I regard it as useless since I am quite content to use USE, but there are many Ada programmers adamantaly opposed to even your limited acceptable of use clauses. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Robert Dewar @ 1999-07-21 0:00 ` Brian Rogoff 1999-07-22 0:00 ` Robert Dewar 1999-07-22 0:00 ` Robert Dewar 0 siblings, 2 replies; 64+ messages in thread From: Brian Rogoff @ 1999-07-21 0:00 UTC (permalink / raw) On Wed, 21 Jul 1999, Robert Dewar wrote: > In article > <Pine.BSF.4.10.9907201840120.500-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > Regular "use" clauses, inside of declarative regions to limit > their scope > > if one is worried about not being able to tell where a > definition comes > > from. I am not a use-phobe, though I understand that one > should be careful > > with use clauses (and aliasing, and overloading, and access > types, etc.) > > > OK, that's reasonable. But you have to realize that use type > was introduced into the language SPECIFICALLY for people who > reject the above solution. Since there are MANY such people, > there was a strong constituency for this feature. I regard it > as useless since I am quite content to use USE, but there are > many Ada programmers adamantaly opposed to even your limited > acceptable of use clauses. I'm not fond of this aspect of the language design process, since there are features that I think add something to the expressiveness of the language which were omitted because strong constituencies abhorred them. Also, Tucker Taft must have liked this enough to include it, so he really is to blame. It wasn't designed by committee, you know :-). -- Brian ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Brian Rogoff @ 1999-07-22 0:00 ` Robert Dewar 1999-07-22 0:00 ` Brian Rogoff 1999-07-22 0:00 ` Robert Dewar 1 sibling, 1 reply; 64+ messages in thread From: Robert Dewar @ 1999-07-22 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > I'm not fond of this aspect of the language design process, since there > are features that I think add something to the expressiveness of the > language which were omitted because strong constituencies abhorred them. Well you seem to be saying that a) I am not fond of the fact that useful features that I would have liked have been omitted from the language. They should have payed more attention to people like me. b) I don't like the process whereby they pay attention to what people think, and follow these recommendations :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-22 0:00 ` Robert Dewar @ 1999-07-22 0:00 ` Brian Rogoff 0 siblings, 0 replies; 64+ messages in thread From: Brian Rogoff @ 1999-07-22 0:00 UTC (permalink / raw) On Thu, 22 Jul 1999, Robert Dewar wrote: > In article > <Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > I'm not fond of this aspect of the language design process, > since there > > are features that I think add something to the expressiveness > of the > > language which were omitted because strong constituencies > abhorred them. > > > Well you seem to be saying that > > a) I am not fond of the fact that useful features that I would > have liked have been omitted from the language. They should > have payed more attention to people like me. Exactly!! > b) I don't like the process whereby they pay attention to what > people think, and follow these recommendations No, its just that the wrong people are being paid attention to. :-) -- Brian ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Brian Rogoff 1999-07-22 0:00 ` Robert Dewar @ 1999-07-22 0:00 ` Robert Dewar 1999-07-22 0:00 ` Brian Rogoff 1 sibling, 1 reply; 64+ messages in thread From: Robert Dewar @ 1999-07-22 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: since there > are features that I think add something to the expressiveness of the > language which were omitted care to give examples?? Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-22 0:00 ` Robert Dewar @ 1999-07-22 0:00 ` Brian Rogoff 0 siblings, 0 replies; 64+ messages in thread From: Brian Rogoff @ 1999-07-22 0:00 UTC (permalink / raw) On Thu, 22 Jul 1999, Robert Dewar wrote: > In article > <Pine.BSF.4.10.9907211854070.23477-100000@shell5.ba.best.com>, > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > since there > > are features that I think add something to the expressiveness > of the > > language which were omitted > > care to give examples?? I could, but there's this guy who frequents c.l.a. who gets annoyed at stuff that has been beaten to death before being recycled again and again, with no new information added, so in deference to this fellow, I'll let the thread die, and refer readers to DejaNews :-). -- Brian PS: my two biggest peeves are out mode function params and downward funargs. I'd have been satisfied with Bob Duffs limited access to subprogram but I know you wouldn't have. There are quite a few other things too but those are fairly simple ones that I frequently miss. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Brian Rogoff 1999-07-21 0:00 ` Robert Dewar @ 1999-07-21 0:00 ` Ted Dennison 1999-07-21 0:00 ` Robert A Duff 1999-07-21 0:00 ` Robert Dewar 1 sibling, 2 replies; 64+ messages in thread From: Ted Dennison @ 1999-07-21 0:00 UTC (permalink / raw) In article <Pine.BSF.4.10.9907201840120.500-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > On Tue, 20 Jul 1999, Robert Dewar wrote: > spec problem. I find the idea of "special casing" the operators inelegant; > if anything I'd prefer that operators and functions were more alike and > that one could define new infix operators. But they are *already* a special case, which is the source of the problem. Unline nomal functions, the infix operators can no longer be used in their expected manner (infix) when they are not directly visible. If the following worked: with FooBar; ... Foo FooBar.= Bar ...then perhaps we wouldn't be having this discussion. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Ted Dennison @ 1999-07-21 0:00 ` Robert A Duff 1999-07-21 0:00 ` Robert Dewar 1 sibling, 0 replies; 64+ messages in thread From: Robert A Duff @ 1999-07-21 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > visible. If the following worked: > with FooBar; > ... > Foo FooBar.= Bar > > ...then perhaps we wouldn't be having this discussion. If that were allowed by the standard (assuming you could figure out how to parse it), I would forbid it in my project standards. It defeats the whole purpose of using operator symbols, just as badly as Foo_Bar."="(Foo, Bar). - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Ted Dennison 1999-07-21 0:00 ` Robert A Duff @ 1999-07-21 0:00 ` Robert Dewar 1 sibling, 0 replies; 64+ messages in thread From: Robert Dewar @ 1999-07-21 0:00 UTC (permalink / raw) In article <7n4r4e$5p$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Foo FooBar.= Bar Yech! this is even worse than the prefix notation if you ask me. I very much doubt that this construction (which is by the way syntactically dubious) would satisfy those people for whom use type is a welcome way out of renaming or using prefix notation. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Robert Dewar 1999-07-20 0:00 ` Brian Rogoff @ 1999-07-21 0:00 ` Robert A Duff 1999-07-21 0:00 ` Michael F. Yoder 1 sibling, 1 reply; 64+ messages in thread From: Robert A Duff @ 1999-07-21 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article > I still really dislike "use type". > > Why? You have not clearly stated a reason for this dislike! > > And I certainly have not seen any satisfactory substitute > proposed! Remember the original proposal of the design team was to make the operators visible by default -- you would get the "use type" behavior without writing *anything* extra. This idea was rejected primarily due to upward compatibility concerns, although I think there were some reviewers who just didn't like it (just as some folks here don't like "use type"). I understand the upward compatibility concern, but it really is odd that in Ada ":=" is visible everywhere, but "=" is not. "In" and "not in" are visible everywhere, but "not" is not. I imagine the reasoning of the original design team had to do with which operators are "operators" (in Ada jargon) -- ie user-definable. But that seems like a pretty weak reason, when I normally just want to use the predefined ones. Robert is fond of saying that style rules shouldn't be absolute. Well, I usually agree, but here's one that I think really is absolute: Never, never use dotted notation in a function call if the function name is an operator symbol. If you have something that really needs to be distinguished that carefully, then you shouldn't give it a name like "+". Can anybody think of an example that shows I'm wrong? - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Robert A Duff @ 1999-07-21 0:00 ` Michael F. Yoder 1999-07-21 0:00 ` Robert A Duff 0 siblings, 1 reply; 64+ messages in thread From: Michael F. Yoder @ 1999-07-21 0:00 UTC (permalink / raw) Robert A Duff wrote: > Robert is fond of saying that style rules shouldn't be absolute. Well, > I usually agree, but here's one that I think really is absolute: Never, > never use dotted notation in a function call if the function name is an > operator symbol. If you have something that really needs to be > distinguished that carefully, then you shouldn't give it a name like > "+". Can anybody think of an example that shows I'm wrong? How contrived and lame an example will you admit? :-) I'm pretty sure I have some black-box tests somewhere that work as follows. There's a package P to be tested that declares some operators. Within the black-box test, I declare a package Q that contains identically named operators which implement exactly the same functions; but these use crude and simple (and hopefully obviously correct) methods. Then the test contains code something like this: for <lots of values of L and R> loop Assert(P."+"(L, R) = Q."+"(L, R), "+ is wrong"); Assert(P."-"(L, R) = Q."-"(L, R), "- is wrong"); -- etc. end loop; The selection notation is needed because the operators are homographs and both are used at the same time. Now if this weren't allowed I could have made the operators in Q use a derived type, and added type conversions at appropriate spots. But I only thought of this method because you were threatening to make it necessary. :-) -- ---- Michael Yoder ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-21 0:00 ` Michael F. Yoder @ 1999-07-21 0:00 ` Robert A Duff 0 siblings, 0 replies; 64+ messages in thread From: Robert A Duff @ 1999-07-21 0:00 UTC (permalink / raw) "Michael F. Yoder" <yoder@decada.zko.dec.com> writes: > How contrived and lame an example will you admit? :-) ... > for <lots of values of L and R> loop > Assert(P."+"(L, R) = Q."+"(L, R), "+ is wrong"); > Assert(P."-"(L, R) = Q."-"(L, R), "- is wrong"); > -- etc. > end loop; OK, you win. It occurs to me that "=" might be redefined, too! How do you like this: Assert(P."="(P."+"(L, R), Q."+"(L, R)) = Q."="(P."+"(L, R), Q."+"(L, R)), "something is wrong"); ^ That's the equal on two Booleans, returning Boolean. ;-) ;-) - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Richard D Riehle 1999-07-19 0:00 ` Brian Rogoff @ 1999-07-23 0:00 ` Tucker Taft 1999-08-03 0:00 ` Richard D Riehle 1 sibling, 1 reply; 64+ messages in thread From: Tucker Taft @ 1999-07-23 0:00 UTC (permalink / raw) Richard D Riehle wrote: > > In article <dale-1807991510420001@192.168.0.2>, > dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > > >Export directives -could- do it (and it is not a bad idea at all), > >but we shouldn't forget that Ada already has the ability to export > >-just- the operators we want, and it's called using a private type > >and only advertising the appropriate operations. > > I fully agree that the private type is underused for this purpose. > However, you will need to declare the arithmetic and logical > operators for a private type. This is the ideal place for using > a nested Ops package to restrict the set of operators to exactly > those you want available in your design. > > package P is > type T is private; > -- operations on T > package Ops is > function ">" (L, R : T) return Boolean; > function "+" (L, R : T) return T; > end Ops; > end P; > > Now, use P.Ops makes sense and exports only the operators the > designer feels are appropriate but still restricts them to an > Ops package. Of course, if they were not in the nested Ops package, > one could still invoke the "use type" clause. In the end, I think it > it will be a matter of preference rather than a matter of which is > better. The major difference is that the operators are no longer inherited as part of a derived type definition. In general, the "ops" package idiom was an Ada 83 work-around. Now that we have use-type, I recommend against proliferating it further. There are ways to work with a language, and ways to fight against it. In Ada 95, the "use type" is definitely the language-defined way to deal with operator visibility. In Ada 83, there really wasn't any particularly good language support for operator visibility, so various approaches were adopted. > ... > Richard Riehle > richard@adaworks.com > http://www.adaworks.com > -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-23 0:00 ` Tucker Taft @ 1999-08-03 0:00 ` Richard D Riehle 0 siblings, 0 replies; 64+ messages in thread From: Richard D Riehle @ 1999-08-03 0:00 UTC (permalink / raw) In article <3798E50D.100976B@averstar.com>, Tucker Taft <stt@averstar.com> wrote: >Richard D Riehle wrote: -- Richard's code appended to end of this article to avoid length example >The major difference is that the operators are no longer inherited >as part of a derived type definition. I understand that the inheritance disappears. For the kind of situations involved, that may not be a real problem. >In general, the "ops" package idiom was an Ada 83 work-around. >Now that we have use-type, I recommend against proliferating it further. Yes, the "ops" package was a work-around. A very good one, it turns out. Even with its drawbacks, and there are some, the question is whether it is better to export all the operators on a type or only some. The idea of making a type "private" and declaring the operators was suggested and that is also a good solution. However, for an enumerated type, this is not a good solution. Sometimes I only want an equality operator available on an enumerated type Should I require the client to rename it or should I export it in some explicit way. I would prefer an explicit export that targets only the operators I want the client to have. The "use type", while often useful, may export more than I want. >There are ways to work with a language, and ways to fight against it. >In Ada 95, the "use type" is definitely the language-defined way to >deal with operator visibility. In Ada 83, there really wasn't >any particularly good language support for operator visibility, >so various approaches were adopted. I don't consider the "ops" package as a way to "fight" against the language. It is simply an alternative that sometimes makes sense. The naked use clause, the "use type", the renaming of operators, are all other alternatives that sometimes make sense. A designer must decide which option is most appropriate for the solution. I am pretty certain we do not disagree on this. Richard >> ... >> Richard Riehle >> richard@adaworks.com >> http://www.adaworks.com -- ======================= Original Example Appended Here ======================= >> >> I fully agree that the private type is underused for this purpose. >> However, you will need to declare the arithmetic and logical >> operators for a private type. This is the ideal place for using >> a nested Ops package to restrict the set of operators to exactly >> those you want available in your design. >> >> package P is >> type T is private; >> -- operations on T >> package Ops is >> function ">" (L, R : T) return Boolean; >> function "+" (L, R : T) return T; >> end Ops; >> end P; >> >> Now, use P.Ops makes sense and exports only the operators the >> designer feels are appropriate but still restricts them to an >> Ops package. Of course, if they were not in the nested Ops package, >> one could still invoke the "use type" clause. In the end, I think it >> it will be a matter of preference rather than a matter of which is >> better. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` Dale Stanbrough 1999-07-20 0:00 ` Richard D Riehle @ 1999-07-20 0:00 ` David Kristola 1 sibling, 0 replies; 64+ messages in thread From: David Kristola @ 1999-07-20 0:00 UTC (permalink / raw) dale@cs.rmit.edu.au (Dale Stanbrough) writes: >Richard D Riehle wrote: > >" >Good point. I wouldn't mind having a concise way of saying (eg) "T is > >an integer type with just "+" and "-" operators. But I still prefer > >"use type" to "package Ops". > > We agree up to a certain point. Explicit export directives would > solve the problem, but that is not currently part of Ada. Again, > "use type" is too broad, I think. " > > >Export directives -could- do it (and it is not a bad idea at all), >but we shouldn't forget that Ada already has the ability to export >-just- the operators we want, and it's called using a private type >and only advertising the appropriate operations. > >However this has the disadvantage that you can't use the private >type in all the places that you might want to use an integer type. > >Dale Can't "abstract" be used to remove the unwanted operators from the original package? function "*"(Left, Right : T) is abstract; -- eliminate multiplication --djk, keeper of arcane lore & trivial fluff Home: David95037 at aol dot com Spam: goto.hades@welovespam.com ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` Richard D Riehle 1999-07-18 0:00 ` Dale Stanbrough @ 1999-07-18 0:00 ` jerry 1999-07-19 0:00 ` Vladimir Olensky 1999-07-20 0:00 ` Richard D Riehle 1999-07-19 0:00 ` Elimination of "use" clauses Ted Dennison 2 siblings, 2 replies; 64+ messages in thread From: jerry @ 1999-07-18 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> wrote: : Modula-3, that would solve the problem quite nicely. Since Ada is not : designed to explicitly support opaque types, one must often use : indirection to support this notion. I am unfamiliar with the term 'opaque type', perhaps because I never looked at Modula-3. Can you explain what it means ? -- -- Jerry van Dijk | Leiden, Holland -- Team Ada | jdijk@acm.org -- see http://stad.dsl.nl/~jvandyk ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` jerry @ 1999-07-19 0:00 ` Vladimir Olensky 1999-07-20 0:00 ` Richard D Riehle 1 sibling, 0 replies; 64+ messages in thread From: Vladimir Olensky @ 1999-07-19 0:00 UTC (permalink / raw) jerry@jvdsys.stuyts.nl wrote in message ... >Richard D Riehle <laoXhai@ix.netcom.com> wrote: > >: Modula-3, that would solve the problem quite nicely. Since Ada is not >: designed to explicitly support opaque types, one must often use >: indirection to support this notion. > >I am unfamiliar with the term 'opaque type', perhaps because I never looked >at Modula-3. Can you explain what it means ? > >-- >-- Jerry van Dijk | Leiden, Holland >-- Team Ada | jdijk@acm.org >-- see http://stad.dsl.nl/~jvandyk Have a look at http://www.research.digital.com/SRC/m3defn/html/opaques.html#idx.129 Nice article about usage of M3 opaque types is available at http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` jerry 1999-07-19 0:00 ` Vladimir Olensky @ 1999-07-20 0:00 ` Richard D Riehle 1999-07-20 0:00 ` jerry 1999-07-20 0:00 ` Opaque Types (was Elimination of "use" clauses) David C. Hoos, Sr. 1 sibling, 2 replies; 64+ messages in thread From: Richard D Riehle @ 1999-07-20 0:00 UTC (permalink / raw) In article <FF2ECA.76@stuyts.nl>, jerry@jvdsys.stuyts.nl wrote: >I am unfamiliar with the term 'opaque type', perhaps because I never looked >at Modula-3. Can you explain what it means ? I will answer this question with the warning that my examples are simply a repetition of already well-known coding practices. Also, even though the Ada code will seem slightly longer than the Modula-3, there are good reasons to prefer the Ada. Even so, the ease of creating opaque types in Modula-3 is an attractive features of that language. An "opaque type" is a type in which all the details of the type are encapsulated in an implementation part of a module. This is required in Modula-3. Ada allows us to promote some of the definition to the private part of the specification. Ada also allows us to defer the details to the pacakge body. The opaque type is commonly used in Modula-3 where we would use a [limited] private type in Ada. The Modula-3 equivalent of a package specification is now called the INTERFACE and equivalent of the package body is called a MODULE. Modula-3 does not have a private part in the INTERFACE. Consider classic generic Stack example in Modula-3, GENERIC INTERFACE Stack (SomeElementType); TYPE Stack_Type <: REFANY; (* procedures for push and pop); END Stack; GENERIC MODULE Stack(SomeElementType); REVEAL Stack_Type = more details for the stack type implementation of push, pop, etc. END Stack; My appreciation to MODULA-3 experts who might notice some syntatic error in my example. The REVEAL command gives the full definition of the type from the INTERFACE. In Ada, a generic stack might be designed several ways. We first show the common textbook example. generic type StackElementType is private; Max : Positive := 100; package Stack is type Stack_Type is limited private; -- declarations for push, pop, etc. private type Stack_Array is array(Positive range <>) of StackElementType; type Stack is record Top : Natural := 0; Data : Stack_Array(1..Max); end record; end Stack; In this example, the private part contains all the information about the structure of the stack. The second Ada example is designed as an "opaque type". generic type StackElementType is private; Max : Positive := 100; package Stack is type Stack_Type is limited private; -- declarations for push, pop, etc. private type Stack_Data; type Stack is access all Stack_Data; end Stack; where there is no information about the structure of the stack, even in the private part. The details of the stack are deferred to the package body. For example, package body Stack is type Stack_Array is array(1..Max) of StackElementType; subtype Stack_Index is range 0..Max; type Stack_Item is record Top : Stack_Index := 0; Data : Stack_Array; end record; -- implement push, pop, etc. end Stack; Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-20 0:00 ` Richard D Riehle @ 1999-07-20 0:00 ` jerry 1999-07-20 0:00 ` Opaque Types (was Elimination of "use" clauses) David C. Hoos, Sr. 1 sibling, 0 replies; 64+ messages in thread From: jerry @ 1999-07-20 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> wrote: :>I am unfamiliar with the term 'opaque type', perhaps because I never looked :>at Modula-3. Can you explain what it means ? : An "opaque type" is a type in which all the details of the type are : encapsulated in an implementation part of a module. This is required : in Modula-3. Ada allows us to promote some of the definition to the : private part of the specification. Ada also allows us to defer the : details to the pacakge body. : In this example, the private part contains all the information about : the structure of the stack. The second Ada example is designed as an : "opaque type". Aha, yes I can see where the term comes from. Although I didn't know it, I have been a heavy user of opaque types in cases where I wanted to hide as much as possible of the actual implementation of the type from the user. Actually, I thought of this of two styles of programming: a) use the package body for only the implementation (i.e. functions and procedures), keep every else as much as possible in the spec. This keeps the body concentrated on the implementation, without being 'distracted' by a lot of deferred definition. Advantages are, IHMO, easier testing. easier finding definitions. It also seems to be in the Ada spirit. However, I sometimes feel unconfortable with this approach, switching to the other style (where Ada allows it): b) use the spec for exporting only information that the client program needs, moving as much as possible to the package body. The advantage is a better encapsulation (hmmm, ok, information hiding). Also usually less inpact when changing some small details. As an old dutch proverb says: 'being consistent is develish', I tend to use both styles. Style b) for things like a File_IO package that has to run on both NT and Linux: single spec, multiple bodies. Style a) for database implementations as these are not directly used by the client of the database package itself. -- -- Jerry van Dijk | Leiden, Holland -- Team Ada | jdijk@acm.org -- see http://stad.dsl.nl/~jvandyk ^ permalink raw reply [flat|nested] 64+ messages in thread
* Opaque Types (was Elimination of "use" clauses) 1999-07-20 0:00 ` Richard D Riehle 1999-07-20 0:00 ` jerry @ 1999-07-20 0:00 ` David C. Hoos, Sr. 1 sibling, 0 replies; 64+ messages in thread From: David C. Hoos, Sr. @ 1999-07-20 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> wrote in message news:7n0hr7$180@dfw-ixnews21.ix.netcom.com... > In article <FF2ECA.76@stuyts.nl>, > jerry@jvdsys.stuyts.nl wrote: > > >I am unfamiliar with the term 'opaque type', perhaps because I never looked > >at Modula-3. Can you explain what it means ? > <large snip> > The second Ada example is designed as an > "opaque type". > > generic > type StackElementType is private; > Max : Positive := 100; > package Stack is > type Stack_Type is limited private; > -- declarations for push, pop, etc. > private > type Stack_Data; > type Stack is access all Stack_Data; > end Stack; > > where there is no information about the structure of the stack, > even in the private part. The details of the stack are deferred > to the package body. For example, > > package body Stack is > type Stack_Array is array(1..Max) of StackElementType; > subtype Stack_Index is range 0..Max; > type Stack_Item is record > Top : Stack_Index := 0; > Data : Stack_Array; > end record; > -- implement push, pop, etc. > end Stack; > Didn't you mean something more like the following? (The type declared in the body is not a completion of the incomplete type Stack declared in the private part). generic type StackElementType is private; Max : Positive := 100; package Stack is type Stack_Type is limited private; -- declarations for push, pop, etc. private type Stack_Item; type Stack_Type is access all Stack_Item; end Stack; package body Stack is type Stack_Array is array(1..Max) of StackElementType; subtype Stack_Index is Integer range 0 .. Max; type Stack_Item is record Top : Stack_Index := 0; Data : Stack_Array; end record; -- implement push, pop, etc. end Stack; That asked, I now have another question, or two, viz.: 1. Is the value of an opaque type worth giving up the flexibility of a discriminated type wherein the stack size does not need to be a formal parameter of the generic package, or have I missed a way to have a discriminated opaque type? 2. In a similar vein, it seems that opaque controlled types are not possible. Is this true. Perhaps a more general question is -- is there really any value in making a limited private type opaque? If so, what is that advantage? David C. Hoos, Sr. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-18 0:00 ` Richard D Riehle 1999-07-18 0:00 ` Dale Stanbrough 1999-07-18 0:00 ` jerry @ 1999-07-19 0:00 ` Ted Dennison 1999-07-19 0:00 ` Tucker Taft 2 siblings, 1 reply; 64+ messages in thread From: Ted Dennison @ 1999-07-19 0:00 UTC (permalink / raw) In article <7mrjus$bet@dfw-ixnews14.ix.netcom.com>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > for every operator on a type. Now, if use type allowed a list of the > operators to be restricted ... For example, > > use type X.T ("=", "<", "/"); > > one would be able to designate exactly which operators were appropriate Ohhhhh. I *like* that idea. Currently "use type" seems a bit sloppy. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-19 0:00 ` Elimination of "use" clauses Ted Dennison @ 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Ted Dennison 0 siblings, 1 reply; 64+ messages in thread From: Tucker Taft @ 1999-07-19 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <7mrjus$bet@dfw-ixnews14.ix.netcom.com>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > > > for every operator on a type. Now, if use type allowed a list of the > > operators to be restricted ... For example, > > > > use type X.T ("=", "<", "/"); > > > > one would be able to designate exactly which operators were > appropriate > > Ohhhhh. I *like* that idea. Currently "use type" seems a bit sloppy. Oh dear, to each his own. It seems strange that you are deciding at the point of use which operators are "appropriate." If there are inappropriate operators, they shouldn't be declared in the package, and shouldn't be primitive. I can't think of a type where "<" is appropriate but ">" is not. Can you give a realistic example? This seems like overkill, IMHO. > T.E.D. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-19 0:00 ` Tucker Taft @ 1999-07-19 0:00 ` Ted Dennison 0 siblings, 0 replies; 64+ messages in thread From: Ted Dennison @ 1999-07-19 0:00 UTC (permalink / raw) In article <37934672.E401493E@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Ted Dennison wrote: > > Ohhhhh. I *like* that idea. Currently "use type" seems a bit sloppy. > > I can't think of a type where "<" is appropriate but ">" is not. > Can you give a realistic example? This seems like overkill, > IMHO. Well...no. My angle on this was that as a developer I much prefer explicitly stating what I'm getting from where. Using full dot notation for packages is part of that. In the case of "use type", I'd feel a lot better saying which routines I need, rather that using a construct that in effect says, "give me all the operations, whatever they may be." But you are right. I can't think of a good example where getting "=" would be fine, but I don't want "-". Perhaps my Modula-2 bias is just acting up again. (I'd better get that checked...) -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Robert Dewar @ 1999-07-02 0:00 ` Stephen Leake 1999-07-02 0:00 ` Ed Falis 2 siblings, 0 replies; 64+ messages in thread From: Stephen Leake @ 1999-07-02 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > In article <7lh74s$v36$1@nnrp1.deja.com>, > Robert Dewar <dewar@gnat.com> wrote: > > In article <377B5807.88B875E0@cs.york.ac.uk>, > > Neil.Audsley@cs.york.ac.uk wrote: > > > > > > We have a lot of Ada source that "with"s and "use"s a lot of > > packages -- > > > to the extent that it is difficult and time-consuming to find > > out which > > > package a procedure is actually from. > > I don't know of a dotification tool, but it seems strange to > > claim that it is difficult and time-consuming to find out > > which package a procedure is from. That sounds like you are > > not using appropriate tools. Try using the EMACS interface > > While I appreciate the fact that *some* compiler systems have facilites > to help decipher stuff like this under *certian* circumstances, I am not > persuaded that obtuse source code is just a "tool problem". > > If I have to use specialized tools to figure out what someone's source > code is doing, the tool that springs most readily to mind is a baseball > bat... The code reading tool is no more "specialized" than the compiler! Borland provides a similar tool for C++, and DEC Ada 83 provided a similar tool in conjunction with LSE. ObjectAda and GNAT both provide such tools; I would reject any compiler that did not. With such a tool, you can understand more complex programs than without such a tool. It is just one more aspect of the art of programming. Of course, there is no substitute for well written code, but I have no problem assuming the availability of appropriate code reading tools when judging what is well written. For instance, I find it harder to read code without syntax colorization. I don't think this is a problem, since colorization is so widely available. The same is now true of cross reference tools; they are widely available, so I am comfortable relying on them. -- Stephe ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Stephen Leake @ 1999-07-02 0:00 ` Ed Falis 2 siblings, 0 replies; 64+ messages in thread From: Ed Falis @ 1999-07-02 0:00 UTC (permalink / raw) In article <7ligdq$c8q$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > While I appreciate the fact that *some* compiler systems have facilites > to help decipher stuff like this under *certian* circumstances, I am not > persuaded that obtuse source code is just a "tool problem". > > If I have to use specialized tools to figure out what someone's source > code is doing, the tool that springs most readily to mind is a baseball > bat... Aside from the fact that using a compiler system that doesn't provide this kind of capability is a bit obtuse these days, I'd have to say that I find code cluttered with extra identifiers and so on more than code that makes use of context with disambiguation where necessary. If the namespace within a unit requires selected notation to be understandable, there's a good chance the sucker is much too big. I've been doing some pretty serious programming in Eiffel lately, with a fair amount of multiple inheritance. The language doesn't use anything like selected notation, and doesn't even have explicit context clauses. But with decent browsing available, I never miss them at all. And I mainly use the browsing just to look at interfaces. The code tends to be clean and understandable, with a clear structure. This is not a language-specific issue. It's a matter of how one does things, and of standardized expectations (as Robert is also inclined to say). - Ed Falis Aonix Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Samuel T. Harris 1999-07-02 0:00 ` Ted Dennison @ 1999-07-02 0:00 ` Ed Falis 1999-07-03 0:00 ` Joe Wisniewski 1999-07-13 0:00 ` Peter Amey 2 siblings, 2 replies; 64+ messages in thread From: Ed Falis @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lh74s$v36$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> wrote: > I don't know of a dotification tool, but it seems strange to > claim that it is difficult and time-consuming to find out > which package a procedure is from. That sounds like you are > not using appropriate tools. Try using the EMACS interface > to GNAT, and you can immediately go from any identifier to > the declaration (and the proper package in which this > declaration appears). This is actually much more useful in > reading code, since you immediately find out not only what > package the identifier is in, but you go to the declaration > which shows you the details of what the identifier means. > > There are other tools that have this same capability. This > seems pretty important functionality. There is also the gnatfind > utility available with GNAT for providing this same kind of > information in command line mode. I have to agree (strongly) with this comment. There's little reason these days not to use such a browsing capability. This allows you to take advantage of the benefit of use clauses: uncluttering the source text so you can easily understand it logic and structure. With resolution of references a click or two away, there's little excuse for long dotted-notation references. - Ed Falis Aonix Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Ed Falis @ 1999-07-03 0:00 ` Joe Wisniewski 1999-07-03 0:00 ` Ed Falis 1999-07-03 0:00 ` Keith Thompson 1999-07-13 0:00 ` Peter Amey 1 sibling, 2 replies; 64+ messages in thread From: Joe Wisniewski @ 1999-07-03 0:00 UTC (permalink / raw) Ed Falis wrote in message <7lj9lb$mos$1@nnrp1.deja.com>... >In article <7lh74s$v36$1@nnrp1.deja.com>, > Robert Dewar <dewar@gnat.com> wrote: > > >> I don't know of a dotification tool, but it seems strange to >> claim that it is difficult and time-consuming to find out >> which package a procedure is from. That sounds like you are >> not using appropriate tools. Try using the EMACS interface >> to GNAT, and you can immediately go from any identifier to >> the declaration (and the proper package in which this >> declaration appears). This is actually much more useful in >> reading code, since you immediately find out not only what >> package the identifier is in, but you go to the declaration >> which shows you the details of what the identifier means. >> >> There are other tools that have this same capability. This >> seems pretty important functionality. There is also the gnatfind >> utility available with GNAT for providing this same kind of >> information in command line mode. > >I have to agree (strongly) with this comment. There's little reason these >days not to use such a browsing capability. This allows you to take >advantage of the benefit of use clauses: uncluttering the source text so you >can easily understand it logic and structure. With resolution of references >a click or two away, there's little excuse for long dotted-notation >references. > Just a rambling thought or two .... Yes and no.Too many organizations still do reviews off of hard-copy. Yes, they should and eventually will do the reviews on line, get comments to the author on line, etc. In these cases, the author is going to be told to get rid of the use clauses anyway. So, in practice, it is going to be a while before use clauses are accepted. Joe >- Ed Falis >Aonix > > >Sent via Deja.com http://www.deja.com/ >Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-03 0:00 ` Joe Wisniewski @ 1999-07-03 0:00 ` Ed Falis 1999-07-03 0:00 ` Keith Thompson 1 sibling, 0 replies; 64+ messages in thread From: Ed Falis @ 1999-07-03 0:00 UTC (permalink / raw) In article <931016222.255.99@news.remarQ.com>, "Joe Wisniewski" <wisniew@acm.org> wrote: > > Just a rambling thought or two .... > > Yes and no.Too many organizations still do reviews off of hard-copy. > Yes, > they should and eventually will do the reviews on line, get comments to > the > author on line, etc. In these cases, the author is going to be told to > get > rid of the use clauses anyway. So, in practice, it is going to be a > while before > use clauses are accepted. > > Joe Which is too bad. I've seen a lot of atrocities in the name of Ada over the years. Common-sense (at least as I define it ;-) seems not to go around as much as it ought to. - Ed Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-03 0:00 ` Joe Wisniewski 1999-07-03 0:00 ` Ed Falis @ 1999-07-03 0:00 ` Keith Thompson 1 sibling, 0 replies; 64+ messages in thread From: Keith Thompson @ 1999-07-03 0:00 UTC (permalink / raw) "Joe Wisniewski" <wisniew@acm.org> writes: [...] > Just a rambling thought or two .... > > Yes and no. Too many organizations still do reviews off of > hard-copy. Yes, they should and eventually will do the reviews on > line, get comments to the author on line, etc. In these cases, the > author is going to be told to get rid of the use clauses anyway. At a previous job, we did code reviews from hard-copy. It enabled us to get half a dozen or so people sitting around a table, reading the code and talking about it. Certainly the technology exists to do the same kind of thing from soft copy, but realistically most employers aren't willing to deploy the resources to give everyone net-connected laptops, or to put multiple PCs in each conference room. Anything other than face-to-face discussion (for example, doing code reviews by e-mail) loses the rapid interaction. (Of course, there were no use clauses in the C code we were reviewing -- or, if you prefer, it was full of nasty implicit ones.) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Elimination of "use" clauses 1999-07-02 0:00 ` Ed Falis 1999-07-03 0:00 ` Joe Wisniewski @ 1999-07-13 0:00 ` Peter Amey 1 sibling, 0 replies; 64+ messages in thread From: Peter Amey @ 1999-07-13 0:00 UTC (permalink / raw) Ed Falis wrote: [snip]. > > I have to agree (strongly) with this comment. There's little reason these > days not to use such a browsing capability. This allows you to take > advantage of the benefit of use clauses: uncluttering the source text so you > can easily understand it logic and structure. With resolution of references > a click or two away, there's little excuse for long dotted-notation > references. > > - Ed Falis > Aonix > There seems to be an assumption in parts of this thread that "dotted.names" = "long.or.unwieldy.dotted.names". I don't think that this has to be the case as long as package and other identifier names are chosen so that they read well when put together with dots (exactly as I hope we would when choosing record and field names). A particular common area of failure in this respect are "bucket" packages containing type declarations. For example, if we have: package BasicTypes is type SwitchType is (On, Off, Unknown); type ValveType is (Open, Closed, Unknown); end BasicTypes; then variable declarations take the (horrible) form: X : BasicTypes.ValveType; Y : BasicTypes.SwitchType; and expressions using them become (in the absence of use clauses) become: if X = BasicTypes.Open and Y = BasicTypes.Off ... I think this is much better handled by using more, smaller packages (recognising that switches and valves are different things) thus: package Switch is type T is (On, Off, Unknown); end Switch; package Valve is type T is (Open, Closed, Unknown); end Valve; which leads to the much nicer declarations: X : Valve.T; Y : Switch.T; and expressions of the form: if X = Valve.Open and Y = Switch.Off ... I think it is better to choose names that read nicelty in context than to use extensive renaming (especially abbreviations) to get round badly-chosen names. I think this means I agree with Robert about the need to control the global name space. regards Peter -- --------------------------------------------------------------------------- __ Peter Amey, Product Manager ) Praxis Critical Systems Ltd / 20, Manvers Street, Bath, BA1 1PX / 0 Tel: +44 (0)1225 466991 (_/ Fax: +44 (0)1225 469006 http://www.praxis-cs.co.uk/ -------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~1999-08-03 0:00 UTC | newest] Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-07-01 0:00 Elimination of "use" clauses Dr. Neil C. Audsley 1999-07-01 0:00 ` czgrr 1999-07-01 0:00 ` Ted Dennison 1999-07-02 0:00 ` czgrr 1999-07-02 0:00 ` Ted Dennison 1999-07-01 0:00 ` Samuel T. Harris 1999-07-01 0:00 ` Joe Wisniewski 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Samuel T. Harris 1999-07-02 0:00 ` Robert Dewar 1999-07-08 0:00 ` R. Tim Coslet 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` tmoran [not found] ` <7ltl2q$mog$1@nnrp1.deja.com> 1999-07-08 0:00 ` Michael F. Yoder 1999-07-09 0:00 ` Robert Dewar 1999-07-09 0:00 ` Dale Stanbrough 1999-07-12 0:00 ` Robert Dewar 1999-07-12 0:00 ` Ted Dennison 1999-07-09 0:00 ` Michael F. Yoder 1999-07-14 0:00 ` Tucker Taft 1999-07-10 0:00 ` Simon Wright 1999-07-12 0:00 ` Robert Dewar 1999-07-09 0:00 ` Richard D Riehle 1999-07-09 0:00 ` Michael F. Yoder 1999-07-09 0:00 ` Marin David Condic 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Robert Dewar [not found] ` <7ltus1$ah1@dfw-ixnews19.ix.netcom.com> 1999-07-13 0:00 ` Robert A Duff 1999-07-18 0:00 ` Richard D Riehle 1999-07-18 0:00 ` Dale Stanbrough 1999-07-20 0:00 ` Richard D Riehle 1999-07-19 0:00 ` Brian Rogoff 1999-07-20 0:00 ` Robert Dewar 1999-07-20 0:00 ` Brian Rogoff 1999-07-21 0:00 ` Robert Dewar 1999-07-21 0:00 ` Brian Rogoff 1999-07-22 0:00 ` Robert Dewar 1999-07-22 0:00 ` Brian Rogoff 1999-07-22 0:00 ` Robert Dewar 1999-07-22 0:00 ` Brian Rogoff 1999-07-21 0:00 ` Ted Dennison 1999-07-21 0:00 ` Robert A Duff 1999-07-21 0:00 ` Robert Dewar 1999-07-21 0:00 ` Robert A Duff 1999-07-21 0:00 ` Michael F. Yoder 1999-07-21 0:00 ` Robert A Duff 1999-07-23 0:00 ` Tucker Taft 1999-08-03 0:00 ` Richard D Riehle 1999-07-20 0:00 ` David Kristola 1999-07-18 0:00 ` jerry 1999-07-19 0:00 ` Vladimir Olensky 1999-07-20 0:00 ` Richard D Riehle 1999-07-20 0:00 ` jerry 1999-07-20 0:00 ` Opaque Types (was Elimination of "use" clauses) David C. Hoos, Sr. 1999-07-19 0:00 ` Elimination of "use" clauses Ted Dennison 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Ted Dennison 1999-07-02 0:00 ` Stephen Leake 1999-07-02 0:00 ` Ed Falis 1999-07-02 0:00 ` Ed Falis 1999-07-03 0:00 ` Joe Wisniewski 1999-07-03 0:00 ` Ed Falis 1999-07-03 0:00 ` Keith Thompson 1999-07-13 0:00 ` Peter Amey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox