Coding guidelines question
in [Fortran]
|
From: Michael Wild on 9 Mar 2006 06:32 the reason i use ONLY is when i want to prevent name clashes. true, i could alias (or whatever the correct term is) the clashing module members, but if i don't need them, i exclude by specifying the components i need with ONLY. michael
From: Dan Nagle on 9 Mar 2006 06:39 Hello, Catherine Rees Lay wrote: > One thing which really, really bugs me about USE statements is ONLY. > > It drives me completely spare when some routine intended to, say, print > a set of information, has an ONLY clause in because at the time it was > written it only printed integer and real information (say), but didn't > need to print any logicals. I fail to see how putting ONLY in to exclude > the logical-printing routine does anything for the structure of the > code, and all it does is add work when you update the printing and now > want to output some logicals as well. I much prefer code written so that > you'd have a bare USE PRINTING, and then you don't have to worry about > changing it to call another printing routine which was there all along. > > If ONLY tells you anything useful at all about the structure of the code > (i.e. this routine only uses the printing routines of the module, not, > say, the file i/o routines) then IMO you should actually put the > structure in at the next level down. By having separate functionality in > separate modules. Otherwise, modifying USE statements becomes such a > common operation that you don't even stop to think about whether this is > a sensible thing to do (say, adding an ONLY reference to print the > logicals) or a messup of the code structure (say, adding a reference to > a file i/o routine, or some calculation, in the middle of a printing > subroutine). Modifying USE statements should, IMO, be something that is > almost never done. > > Okay, off the soapbox now :-) > > Catherine. OK, my turn! :-) Are you sure this isn't a good time for a generic procedure? The generic name is made public, the specific names are kept private. When you use the output routine (or whichever) with a new TKR, the compiler resolves the reference without modifying the use statement. Next? -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc.
From: Arjen Markus on 9 Mar 2006 06:58 A bare PRIVATE keyword makes everything private, unless you explicitly declare it PUBLIC, this is even true for things imported via USE (or at least that is the effect that I have seen with a number of compilers): module A contains subroutine AA write(*,*) 'Called AA' end subroutine end module module B use A private end module B program aha use B call AA ! This should fail end program Regards, Arjen
From: Catherine Rees Lay on 9 Mar 2006 09:29 Dan Nagle wrote: > Hello, > > Catherine Rees Lay wrote: >> One thing which really, really bugs me about USE statements is ONLY. >> >> It drives me completely spare when some routine intended to, say, >> print a set of information, has an ONLY clause in because at the time >> it was written it only printed integer and real information (say), but >> didn't need to print any logicals. I fail to see how putting ONLY in >> to exclude the logical-printing routine does anything for the >> structure of the code, and all it does is add work when you update the >> printing and now want to output some logicals as well. I much prefer >> code written so that you'd have a bare USE PRINTING, and then you >> don't have to worry about changing it to call another printing routine >> which was there all along. >> >> If ONLY tells you anything useful at all about the structure of the >> code (i.e. this routine only uses the printing routines of the module, >> not, say, the file i/o routines) then IMO you should actually put the >> structure in at the next level down. By having separate functionality >> in separate modules. Otherwise, modifying USE statements becomes such >> a common operation that you don't even stop to think about whether >> this is a sensible thing to do (say, adding an ONLY reference to print >> the logicals) or a messup of the code structure (say, adding a >> reference to a file i/o routine, or some calculation, in the middle of >> a printing subroutine). Modifying USE statements should, IMO, be >> something that is almost never done. >> >> Okay, off the soapbox now :-) >> >> Catherine. > > OK, my turn! :-) > > Are you sure this isn't a good time for a generic procedure? > > The generic name is made public, the specific names are kept private. > When you use the output routine (or whichever) with a new TKR, > the compiler resolves the reference without modifying > the use statement. > > Next? > Yes, in that case, it would work. How about a graphics module? Draw line, draw circle, draw polygon... You might be able to twist it to have one generic draw shape routine, but I'd think it much clearer to have draw line with two endpoints, draw circle with a centre and a radius, draw polygon with a number of corners and an array of coordinates, and so on. And I really, really hate having to modify what I consider to be a description of the code's underlying structure (the USE statement) just because my client has decided that the caterpillar-drawing routine which uses the circle function should also do legs. I think the generic procedure suggestion is a good one, for some cases, but there's no particular reason why routines belonging in the same module should be suitable for it. That would be like suggesting that modules should only make one name public. Catherine.
From: Richard E Maine on 9 Mar 2006 10:51
Arjen Markus <arjen.markus(a)wldelft.nl> wrote: > A bare PRIVATE keyword makes everything private, unless you explicitly > declare it PUBLIC, this is even true for things imported via USE (or at > least that is the effect that I have seen with a number of compilers): Ah... sort of. First, the standard specifies this - not just particular compilers. But second, there is a very subtle quirk in the exact wording of the standard. The quirk is intentional; it matters. The PUBLIC keyword makes things public. That part is ok. You might think that the PRIVATE keyword would make things private, but that's not actually what the standard says. Instead, it has a strangely double negative form. I can cite the exact words (or darned close) even without opening the standard, because thi was once the subject of carefull study in an f90 interp a decade ago. The PRIVATE attribute for an entity specifies that the entity "is not a public entity of the module". Why the negative form? Part of the reason is that "of the module" phrase and it relates to things imported via USE. If some identifier was imported via USE, then that is not a private identifier. If it were, it couldn't have been imported by USE. Nothing that the importing module does can change the fact that the identifier was public in its original module of definition. All that PRIVATE does for such an imported identifier is say that it won't be re-exported (my term) from this module. But that doesn't mean it is private to this module - it can't very well be because it isn't even "owned" by this module. 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". In f90 and f95 it mattered because there were some "funny" restrictions relating to private things, so you needed to know what things those restrictions applied to. I think all those "funny" restrictions are gone in f2003, so the picky distinctions about whether something is or is not "really" private might not matter any more there. -- 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 |