#385 Grid::name() should be static
Metadata
| Property | Value |
|---|---|
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Apr 26, 2008 14:37 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | Dec 29, 2009 10:54 |
| Closed by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Closed at | Dec 29, 2009 10:54 |
| Closed in version | 2.0 |
| Resolution | Implemented |
| Comment | Method marked as deprecated in revision 6080. Will be removed after the 2.0 release. |
Description
The method name() of the grid implementation classes only prints the grid type and no information for individual objects. Hence it should be static.
Activity
I disagree. Assigning a name to a grid might be quite helpful when working with different grids. Optimally, that name could be set in the grid file. I just added that possibility to the GridParameterBlock of the DGF parser and made AlbertaGrid use it. This make the use of different names possible.
But I guess the real question is: What is the gain of making it static? The method is only used during user interaction anyway...
The real question is: what is the precise meaning of this method? The way it is implemented now, all it does is give you the type of the grid in string form. That is static information, hence the method should be static.
If on the other hand, you want to assign names to grid objects, then of course the method should not be static.
However, actually, I don't really see why a grid object handle such a thing as a 'name' at all. Object names are easily added as external data (e.g., std:map<MyGridType*,std::string>). Type names as well.
-
Well, Oli, let me ask a very stupid question then: What is the gain of the method name anyway? The name of the type is of little interest.
And you're right: The grid's name could always be attached by a map. The question is: If the underlying grid supports attaching a name to a grid, should be ignore such information or should we return it. AlbertaGrid, for example, returns this information by now.
I think this information is most useful when saving grids (for example to implement checkpointing). It is a similar information to the name of a function when using a VTKWriter.
Can we settle this before the 2.0 release? There seem to be three options:
- make the method static, and have it return the grid type as a string
- make the method dynamic, and add a method to set the grid type from the outside
- remove the method altogether, because nobody really needs it.
I herewith call for a formal vote.
I vote for 3).
Felix Albrecht (felix.albrecht@uni-muenster.de) commented on the issue:
If i could vote, i would vote against 3 and for something like 1.
-
Felix Albrecht (felix.albrecht@uni-muenster.de) commented on the issue:
At a certain point i wanted to write some data structures (grid, function space, function,...) to a file and have them loaded at some point later. Therefore i wanted to save the grid type as well. I would just like to obtain some information from the grid at run time to identify the grid (e.g. check, whether i've created a grid out of some dgf file with the right grid type), and i thought this would be the method to get that information.
