Andreas L. Delmelle wrote:
[(*) = OT: instead of non-contextually sorting the integer values according
to the alphabetical name of the constants in question, which only _looks_
nice code-wise, but seems to serve no other purpose.
I come from an Oracle database background, so this is quite acceptable
(perhaps even ideal) for me. These constants are like database "primary
keys", and hence their uniqueness and complete lack of business logic to
their individual values is usually a proper design.
If this were a database table and I were the DBA, rather than me
ordering the primary key values in such a way that the business logic
below could directly rely on them, I would create another table column,
specifically name in "border precedence" or something, and then hardcode
the 1-2-3-etc. values in that column.
What does it mean
'EN_DOTTED' is 'enum constant number/value 36'? When/where is that
information ever going to be relevant?
Absolutely nothing and hopefully never, respectively, to
database-centric developers... ;-)
Maybe this line of thinking can also
be applied to other constants...? Admitted, some constants can pop up in a
few different types of situations, so there, we'd need to very careful when
establishing relationships between them at a level so global as the
interface, but in this particular case the keywords are so specific to the
context of border-style, there would be no harm in reserving a set of ints
starting at N and define the constants as:
// Border style constants
EN_INSET = N;
EN_GROOVE = EN_INSET + 1;
EN_SOLID = EN_DASHED + 1;
EN_DOUBLE = EN_SOLID + 1;
and we can conveniently compare two border-style constants to see which one
is 'larger' --in any class that implements the interface, at whatever stage
of processing. There may be other scenarios where such functionality would
be useful... and may avoid having to locally re-establish this type of
relationship between constants in classes implementing Constants.]
I can perhaps rephrase your suggestion in a way that might cause you to
rethink the actual elegance of this idea: What you're suggesting is
that the table formatting business logic (here, the precedence of
various border styles) should be stored and maintained in the Constants
interface, rather than in the relevant layout classes.
But I see your suggestion actually as more of a performance benefit,
because there is no more computationally efficient way to determine the
"larger" value. And since these values can be presumably heavily
queried for a table with many rows and columns, it may beneficial for us
to do this for performance reasons alone. Although another option,
which would probably need to be done anyway if these constants find use
in multiple contexts, is to do a one-time initialization of a static
integer (sparse?) array as follows:
int precedence = new int.....
precedence[EN_INSET] = 1;
precedence[EN_GROOVE] = 2; ... etc.
within the appropriate layout class--keeping this logic nicely
there--and do precedence[EN_XXX] > precedence[EN_YYY], etc. comparisons
instead of EN_XXX > EN_YYY.
But I'm just speculating here--I haven't looked at the code, or (truth
be told...) the relevance of this discussion to the problem at hand.