module variable naming
in [Fortran]
|
Prev: DFPORT
Next: Relocation truncated to fit: continued!
From: Bart Vandewoestyne on 2 Aug 2006 07:51 I often find myself doing something like the following: module mymod public :: init_method public :: run_method integer, private :: q_mod contains subroutine init_method(q) integer, intent(in) :: q q_mod = q end subroutine init_method subroutine run_method(res) integer, intent(out) :: res res = 2*q_mod end subroutine run_method end module mymod program test_module_variable use mymod integer :: y call init_method(3) call run_method(y) print *, "y = ", y end program test_module_variable Now my question is the following: As you can see, i have a module variable `q_mod' which actually represents some variable `q' from an algorithm. The algorithm requires some initialization of q (q_mod) which happens in init_method() and when the algorithm runs, it uses this q (q_mod) in run_method(). Now for reasons of clarity and readability, i would like my module variable to have the name 'q' instead of 'q_mod'. For the same reasons of clarity, it would be nice if the parameter that gets passed to init_method(q) could also still be called 'q'. However, this then would mean that I have something like subroutine init_method(q) integer, intent(in) :: q q = q end subroutine init_method where in the line q=q the left q is my module variable, and the right q is the local variable from the subroutine. In Java, I could write something like this.q = q but somehow I have the feeling that there isn't a solution for this in Fortran 95? As I see it now, i *have* to make sure that my `module variable q' has a different name than my 'local variable q', something like 'q_mod' or 'q_' or '$q' or so... and there is no way to avoid that, or is there? How do you programmers handle situations like this in order to keep maximum clarity and readability in your variable names? Thanks, Bart -- "Share what you know. Learn what you don't."
From: Arno on 2 Aug 2006 08:50 What about: module mymod public :: init_method public :: run_method type my_mod integer :: q end type type (my_mod), private :: this contains subroutine init_method(q) integer, intent(in) :: q this%q = q end subroutine init_method subroutine run_method(res) integer, intent(out) :: res res = 2*this%q end subroutine run_method end module mymod
From: Bart Vandewoestyne on 2 Aug 2006 09:44 On 2006-08-02, Arno <arnoinperu(a)hotmail.com> wrote: > What about: > > module mymod > > public :: init_method > public :: run_method > > type my_mod > integer :: q > end type > > type (my_mod), private :: this > > contains > > subroutine init_method(q) > integer, intent(in) :: q > > this%q = q > > end subroutine init_method > > > subroutine run_method(res) > integer, intent(out) :: res > > res = 2*this%q > > end subroutine run_method > > end module mymod This looks indeed like a nice idea, but it still has the drawback that within run_method() i have to use 'this%q' whereas I would prefer to simply use 'q' (for clarity and simplicity of reading... this%q is being used quite a lot in quite complicated expressions... and I prefer to simply have nice and simple looking 'q' there...). For what I can think of right now, my best option is probably to name my (private) module variable 'q' and name the parameter that is passed to init_method() something 'ugly' like 'q_' or 'q_dummy' or so... because at the beginning of init_method() i can simply write q = q_ and then use q everywhere i need it in init_method() or run_method(). This way, the number of places where the 'ugly q_' appears is reduced to two. Any other suggestions or ideas are of course still welcome. Best wishes, Bart -- "Share what you know. Learn what you don't."
From: highegg on 2 Aug 2006 10:04 Bart Vandewoestyne wrote: > I often find myself doing something like the following: > > module mymod > > public :: init_method > public :: run_method > > integer, private :: q_mod > > contains > > subroutine init_method(q) > integer, intent(in) :: q > > q_mod = q > > end subroutine init_method > > > subroutine run_method(res) > integer, intent(out) :: res > > res = 2*q_mod > > end subroutine run_method > > > end module mymod > > > program test_module_variable > > use mymod > > integer :: y > > call init_method(3) > > call run_method(y) > > print *, "y = ", y > > end program test_module_variable > > > Now my question is the following: > > As you can see, i have a module variable `q_mod' which actually represents > some variable `q' from an algorithm. I think renaming like this is fine if the module variable is private (so that its name only matters within the module). If it is public, you may have better reason for it to have a specific name. > The algorithm requires some > initialization of q (q_mod) which happens in init_method() and when > the algorithm runs, it uses this q (q_mod) in run_method(). > > Now for reasons of clarity and readability, i would like my > module variable to have the name 'q' instead of 'q_mod'. For the > same reasons of clarity, it would be nice if the parameter that > gets passed to init_method(q) could also still be called 'q'. Concerning readability, I don't think that "this.q" is any more readable than "q_mod". But there is also the issue of interface: If a module variable is public, you may have good reason to have it named "dim" not "dim_mod", because the latter is less intuitive to use. On the other hands you may still want to use the keyword "dim" for a dummy argument of a module procedure. The solution is to get rid of the host association which, unlike USE association, doesn't permit renaming (AFAIK). So use something like module mymod_data integer :: q end module module mymod use mymod_data public :: init_method public :: run_method contains subroutine init_method(q) use mymod_data, q_mod => q integer, intent(in) :: q q_mod = q end subroutine init_method subroutine run_method(res) integer, intent(out) :: res res = 2*q_mod end subroutine run_method end module mymod Nothing changes "from outside", except for the additional global module name - this will be probably resolved with submodules, you just have to do more typing. Of course, something like IMPORT q_mod => q for host association would be more convenient, but no language is perfect. Jaroslav
From: Arno on 2 Aug 2006 10:18
> This looks indeed like a nice idea, but it still has the drawback > that within run_method() i have to use 'this%q' whereas I would > prefer to simply use 'q' But as you stated in your first post, you would get something like: q = q How should the compiler know which q is which? There must be lingual difference between the one and the other if the two are different entities. Or am I missing the point? Arno |