Coding guidelines question
in [Fortran]
|
From: Richard E Maine on 9 Mar 2006 13:24 Paul Van Delst <Paul.vanDelst(a)noaa.gov> wrote: > Richard E Maine wrote: > > I personally think that the terminology is unfortunate in that public > > indeed means public, but private doesn't really mean private. Instead, > > private means something closer to "don't export from here". > But, despite this subtlety, isn't the end result what people would > commonly (intuitively?) expect? No. Not even close. If it were, then there wouldn't have been multiple interpretation question about it, compilers that got it wrong (but were fixed after the interps), and users that still misinterpret it. It took a good year to settle on the crucial interp answer. That was a year of actual debate - not including the bureaucratic bits of formalizing the answer. > Public means that entities are "visible from" a module if that module is > PUSEd. rivate means that entities are NOT "visible from" a module if that > Pmodule is USEd. You missed the bit about there being restrictions in the standard. Those restrictions are *NOT* intuitive - not even close. (They were also misguided in the first place, and are finally all gone in f2003, but that's another matter). That's where all the fuss is. Let's see an example of one of those nasty restrictions. How about the 10'th constraint in 5.1 of f95 (if I counted right - it's at page:line [48:15]. "An entity shall not have the public attribute if its type has the private attribute." Apply that to module m2 use m1 private private my_type !-- Unnecessary, but just to make it extra clear. type (my_type), public :: x end module m2 where my_type came from m1. In this module, x is public, and my_type is.... If the answer and all of its implications to that constraint are obvious and intuitive to you, then we need you on the committee because you are really, really good. :-) The answer is that the constraint does not apply because my_type isn't private. It is just "not a public entity of the module", which isn't the same thing. The exact argument and supporting material are subtle; I'm not going to repeat them here. Note that this is a very common style. If you couldn't do this, things would get "bad". And there are other related ones. If this counted as my_type being private, then by the time you were done chasing all the implications, you pretty much would be forced to always make everything public in lots of large apps. That wouldn't have been good. -- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain| experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
From: James Giles on 9 Mar 2006 13:48 The argument that people don't use ONLY because it's too much trouble sound almost identical to the complaints about IMPLICIT NONE. I still think everything visible in a given scope should be declared there. For module entities, all you have to declare is where they came from. The ONLY clause declares the entities, and the corresponding USE says where thay came from. That's hardly much of a hardship. -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
From: Rich Townsend on 9 Mar 2006 13:53 James Giles wrote: > The argument that people don't use ONLY because it's > too much trouble sound almost identical to the complaints > about IMPLICIT NONE. I still think everything visible > in a given scope should be declared there. For module > entities, all you have to declare is where they came from. > The ONLY clause declares the entities, and the corresponding > USE says where thay came from. That's hardly much of > a hardship. > As an alternative, I make sure that in each module all of the public entities have the same prefix, which is unique across differing modules. Hence, I can always tell exactly where every routine, parameter, etc comes from --- and by looking at the actual code where these things are used, rather than having to look back at the ONLY clause. cheers, Rich
From: Richard Edgar on 9 Mar 2006 13:58 James Giles wrote: > The argument that people don't use ONLY because it's > too much trouble sound almost identical to the complaints > about IMPLICIT NONE. I still think everything visible > in a given scope should be declared there. For module > entities, all you have to declare is where they came from. > The ONLY clause declares the entities, and the corresponding > USE says where thay came from. That's hardly much of > a hardship. Just don't forget about removing things from the ONLY list when you delete the _last_ reference to them in the current scoping unit. I would also add that in one code I'm currently using, a USE statement with ONLY tends to end up looking like USE MyModule, ONLY : MyModSubA, MyModSubB, MyModSubC, etc. I wouldn't say that ONLY should never be used, but the more I think about it, the more of a hassle it seems to be in a good number of cases. Richard
From: James Giles on 9 Mar 2006 14:09
Rich Townsend wrote: > James Giles wrote: >> The argument that people don't use ONLY because it's >> too much trouble sound almost identical to the complaints >> about IMPLICIT NONE. I still think everything visible >> in a given scope should be declared there. For module >> entities, all you have to declare is where they came from. >> The ONLY clause declares the entities, and the corresponding >> USE says where thay came from. That's hardly much of >> a hardship. > > As an alternative, I make sure that in each module all of the public > entities have the same prefix, which is unique across differing > modules. > > Hence, I can always tell exactly where every routine, parameter, > etc comes from --- and by looking at the actual code where these > things are used, rather than having to look back at the ONLY clause. I almost wrote a second paragraph in the above denouncing that very practice. That means that all the entities from modules have very verbose names (which I usually have to rename anyway if I plan to use them several times - just to avoid that problem). If legibility is important, using novels as identifiers is counterproductive. Not to mention overloaded operators - just a few days ago I posted an overloaded concatenate operator. How do you propose to name it so that you can tell what module it's from? And, during code development, the proper packaging changes from time to time. If I move an entity from one module to another, but I'm using ONLY clauses, I merely have to change the module name on the USE statement. If I have these verbose names that contain the module name within them, I have to change every use throughout the code. And, what of submodules? Do the names of the entities have the parent's module name as part of their own names? Or the submodule's name? Both? Finally, if using an ONLY clause is a hardship, isn't writing all those long names throughout the code even more of a hardship? -- J. Giles "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare |