Re: Smuggling information to enums
Roedy Green wrote:
On 24 Mar 2009 15:33:02 GMT, Andreas Leitgeb
<firstname.lastname@example.org> wrote, quoted or indirectly quoted
someone who said :
Does it at least seem as if I had understood your question?
Yes, you understood. I was hoping I had overlooked something.
In my case I was rewriting my CSVReader to use enums. A CSVReader can
be configured with the various characters you want to use for
separator, quote and comment. The enum needs to know these facts.
What are the enum values supposed to stand for? Token types
in the parsed input, like "This substring is a field separator"
or "This substring is an empty or all-space field," where the
notions of what characters/sequences are separators or are spaces
If that's the goal, I don't think the individual enum values
like FIELD_SEPARATOR or EMPTY_FIELD need to know anything about
the character sequences. Rather, a particular CSVReader instance
needs to be ablt to map character sequences to enum values in its
own idiosyncratic way.
Further there could be two different CSVReader objects in RAM at once.
That means I would want two versions of the enum, each with a
different set of instance data.
... in which case enum is almost certainly the wrong tool.
A particular enum value is a, is a, well "singleton" is wrong
because there can obviously be multiple instances of the same enum
class. But in that class there is only one enum instance with a
given ordinal, hence == and .equals() are about the same (only "about"
because == won't throw NPE for a null enum reference). If there is
only one Foo.Enum with the ordinal 4 -- FIELD_SEPARATOR, say -- it
has only one internal state and can't look different when viewed
from different clients.
I think the way it will have to work is pass in the magic constants on
every call as parameters so that only one uncustomised copy of the
enum is needed.
The parms on the enum constant constructors pretty well have to be
constants, or something public and static since almost nothing is
known in the context of those parms.
Pretty much anything *can* be known, so long as it's known
before the enum instance is constructed. The constructor for an
enum instance can get the time of day, generate random numbers,
read files, even display dialog boxes and get user input. (I'm
not advocating such practices, just dramatizing a point.)