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

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.

Reply via email to