In preparing HexGridNumberingX for automated import to VASSAL modules, I spotted what I believe to be an implemenatation mistake through-out much of VASSAL. Whereas the Configurable i/f defines the method getConfigureName(), which is defined in AbstractConfigurable, most of the implementing classes and their invokers seem to be instead using the method getConfigureTypeName(). This is pervasive. Am I correct, or am I missing some subtlety in the definitions?
Pieter
They serve different functions. getConfigureTypeName returns a constant that
describes the type of component. getConfigureName returns the user-settable
name of the component and probably shouldn’t be overridden.
On 15 December 2010 07:34, pgeerkens pgeerkens@hotmail.com wrote:
In preparing HexGridNumberingX for automated import to VASSAL modules, I
spotted what I believe to be an implemenatation mistake through-out much
of VASSAL. Whereas the Configurable i/f defines the method
getConfigureName(), which is defined in AbstractConfigurable, most of
the implementing classes and their invokers seem to be instead using the
method getConfigureTypeName(). This is pervasive. Am I correct, or am I
missing some subtlety in the definitions?Pieter
Should getConfigureTypeName() be added to Configurable and AbstractConfigurable then? It seems to be a necessary requirement for successful invocation of the Configurable i/f.
Pieter
As far as I can tell, getConfigureTypeName() is only ever called by
getComponentTypeName(), which in turn is only ever used to detect infinite
loops. It is therefore declared in the RecursionLimiter.Loopable interface.
So the answer is mostly no. If anything, it’s just kind of named badly.
Hope that helps 
On 15 December 2010 08:11, pgeerkens pgeerkens@hotmail.com wrote:
Should getConfigureTypeName() be added to Configurable and
AbstractConfigurable then? It seems to be a necessary requirement for
successful invocation of the Configurable i/f.Pieter
But if implementation of i/f Configurable is defined as the necessary and sufficient condition to be ‘configurable’, and implementing getConfigureTypeName() is a necessary condition to be ‘configured’, then ipso facto getConfigureTypeName() seems to belong in, or in a super-class of, i/f Configurable (or at least of abstract class AbstractConfigurable).
I have no idea what you just wrote. However, it sounds like your making some assumptions that may not be true.
getConfigureTypeName() is most certainly not a necessary method for all classes that implement Configurable.
On 2010-12-15, at 12:18 PM, pgeerkens pgeerkens@hotmail.com wrote:
But if implementation of i/f Configurable is defined as the necessary
and sufficient condition to be ‘configurable’, and implementing
getConfigureTypeName() is a necessary condition to be ‘configured’, then
ipso facto getConfigureTypeName() seems to belong in, or in a
super-class of, i/f Configurable (or at least of abstract class
AbstractConfigurable).
Read this topic online here:
getConfigureName() or getConfigureTypeName() ? - #5 by pgeerkens
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
Ok, I will check that out. It seemed necessary last night, but perhaps that was one of the dead-ends I travelled down yesterday.
Yes, I am good at baffling with bullshit sometimes. When I revert, please do call me on it.