[ET Trac] [Einstein Toolkit] #1233: McLachlan should not define one-character variables
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Sun Jan 27 03:48:12 CST 2013
#1233: McLachlan should not define one-character variables
------------------------------------+---------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Resolution: | Keywords:
------------------------------------+---------------------------------------
Comment (by hinder):
I do not like this solution. I think the code should be easily readable
by someone who is familiar with the problem domain; i.e. the BSSN
equations. In that domain, quantities like H, K, A, etc are understood to
have certain meanings. Name conflicts are usually handled by some
namespace feature. Your suggestion is a low-tech version of this. I
worry that the code would rapidly become unreadable and much longer.
Taking your suggestion to its logical conclusion, no thorn which ever
expects to be inherited from could use simple, easy-to-understand, names
for its grid functions. If a thorn chooses to inherit from another thorn,
it should make sure not to use variables which are defined by the public
interface of that thorn.
Why do you say it is impossible to use single-character variables in
thorns inheriting from McLachlan? You just need to avoid shadowing the
variables by choosing your temporary variable names so that they don't
conflict. I assume the compiler warns about shadowed variable
declarations, in which case you can rename your temporary variable when
you see that warning.
One practical problem with changing the variable names is that existing
parameter files which list these variables by name for output would become
invalid, and this is always frustrating.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1233#comment:1>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list