From: Rich Townsend on 9 Mar 2006 22:52 James Giles wrote: > Rich Townsend wrote: > ... > >>Well, I'm coming at things from a namespace standpoint. If each module >>has a different prefixing scheme, then there's no need to worry about >>namespace conflicts. Without the scheme (or some other approach), one >>has to start using ONLY to do renaming -- and in my eyes that is a sin >>before God. :) > > > Well, I come at these things from the point of view > of namespace management too. The only time I have > more than one thing in a given scope with the same > name is when it's generic. I tend to only use renaming > for things from the dreaded "someone else's module". > I have yet to need any prefix codes to tell me where > things are from. Usually I don't care. If I do, I want > very much to always be able to tell by looking at the > local declarations. (I don't want to have to maintain > a table of what prefix codes go with what module > name either. I don't quite see how two letter prefixes > can really be mnemonic.) > Let me give a concrete example, and see if you can suggest how to go about things using your approach (which I'm interested to hear about -- if I can dump the prefixes with no consequences, then I'm all for it). In my cubic spline module, there is a routine sl_interp_y(), which performs spline interpolation on tabulated (ie, y vs. x) data. I also have a module that provides a routine ft_interp_y() --- it does the same operation, but uses linear interpolation instead of spline. If I dumped the prefixes, then these two procedures would clash via the TKR rules. Now, I could merge the routines; but I'd rather keep all the spline stuff in the spline module, and all of the linear stuff in the linear module. Any thoughts? cheers, Rich
From: Dan Nagle on 9 Mar 2006 23:06 Rich Townsend wrote: <snip> > If I dumped the prefixes, then these two procedures would clash via the > TKR rules. Now, I could merge the routines; but I'd rather keep all the > spline stuff in the spline module, and all of the linear stuff in the > linear module. Any thoughts? Can you define a type for spline data, and another for the linear data? -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc.
From: Rich Townsend on 9 Mar 2006 23:34 Dan Nagle wrote: > Rich Townsend wrote: > > <snip> > >> If I dumped the prefixes, then these two procedures would clash via >> the TKR rules. Now, I could merge the routines; but I'd rather keep >> all the spline stuff in the spline module, and all of the linear stuff >> in the linear module. Any thoughts? > > > Can you define a type for spline data, and another for the linear data? > Yes, I already have types, and routines that operate on them. But the specific interpolation functions I mention above are "shortcut" routines that operate on real array arguments. In essence, they do the following: 1) Create an appropriately-initialized instance of the type, from array arguments 2) Pass the instance to the typed interpolation routine 3) Return the results to the caller 4) Throw away the instance; this is done implicitly, since the instance (stored in a local var) goes out of scope at the end of the routine cheers, Rich
From: James Giles on 9 Mar 2006 23:42 Dan Nagle wrote: > Rich Townsend wrote: > > <snip> > >> If I dumped the prefixes, then these two procedures would clash via >> the TKR rules. Now, I could merge the routines; but I'd rather keep >> all the spline stuff in the spline module, and all of the linear >> stuff in the linear module. Any thoughts? > > Can you define a type for spline data, and another for the linear > data? That was my first thought. Another is to question how often (other than in testing) that you have two different interpolation methods in use from within the same scope? In most production code you would pick one interpolation method (for speed or accuracy or the best compromise between them) and not even USE the other. I can see that you might USE both in a comparison - that perhaps is a classic, though rare, need for a rename. Finally (unless I think of something else later), this is actually a case where traditionally the routines might have different names anyway. It's just not usual that the difference necessarily has anything to do with the location of the codes. Some people might have put them in a single module of interpolation routines of which these are two of many. Certainly in the old days they'd both likely be in the same library of external procedures. The difference in name is more related to what they do, not to where they're from. I'd have to know more about why you need to access both in the same scope before I could go any further on this. There are some more choices in F2003 (type-bound procedures, for a start). -- 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 10 Mar 2006 00:27
James Giles wrote: > Dan Nagle wrote: > >>Rich Townsend wrote: >> >><snip> >> >>>If I dumped the prefixes, then these two procedures would clash via >>>the TKR rules. Now, I could merge the routines; but I'd rather keep >>>all the spline stuff in the spline module, and all of the linear >>>stuff in the linear module. Any thoughts? >> >>Can you define a type for spline data, and another for the linear >>data? > > > That was my first thought. > > Another is to question how often (other than in testing) that you > have two different interpolation methods in use from within the > same scope? In most production code you would pick one > interpolation method (for speed or accuracy or the best compromise > between them) and not even USE the other. I can see that you might > USE both in a comparison - that perhaps is a classic, though rare, > need for a rename. > > Finally (unless I think of something else later), this is actually > a case where traditionally the routines might have different names > anyway. It's just not usual that the difference necessarily has anything > to do with the location of the codes. Some people might have put > them in a single module of interpolation routines of which these > are two of many. Certainly in the old days they'd both likely be > in the same library of external procedures. The difference in > name is more related to what they do, not to where they're from. > > I'd have to know more about why you need to access both in the > same scope before I could go any further on this. There are some > more choices in F2003 (type-bound procedures, for a start). > I'm interpolating variables relating to the internal structure of a star. Some of these variables are guaranteed to vary smoothly, without discontinuities (e.g., the pressure), and are therefore good candidates for spline interpolation. Others can show discontinuities (e.g., Brunt-Vaiasala frequency, which shows a trapezoidal-like peak around the cores of massive stars), and require linear interpolation, since splines would introduce ringing around the discontinuity. cheers, Rich |