Andrew Dunstan <andrew@dunslane.net> writes:
> Well, for one thing, I have no plan to allow explicit setting of the internal
> representational value, as one can do in C. And the fact that it's an int
> underneath is in implementation detail, IMNSHO. After all, KL just advised
> using a text domain with a check constraint for enums, so int storage is
> hardly a fundamental part of enum-ness.
Well it is in that there's not much point to them if it's not. That is, you
can _already_ use a text domain with check constraints if you want. The only
point to enums is to let you get the syntax niceness that provides without
burdening the implementation with any costs.
That is, the whole point of enums is to let you have your cake and eat it to.
You get to give the programmers a nice safe interface but tell your DBA you're
storing the most space efficient storage format possible.
If you don't get that then you may as well use integers or text strings as you
prefer.
> Maybe this all just reflects my background in languages that are more strongly
> typed than C and have first class enums.
I suspect this is a matter of perspective. If you speak to the programmers
they're liable to agree with you that these languages give this abstract enum
thing that could just as easily be stored as strings. But if you speak to the
language designers they'll tell you that the whole point was to package up an
integer-backed storage in an abstract way and if you implemented them as text
there wouldn't have been any point in having them in the language.
Even languages like lisp treat symbols as integers internally. The whole point
of having symbols is to give an abstraction that programmers can use to hide
the internally grungy details that allow reasonably efficient implementations.
symbols in lisp can be stored and compared efficiently because they're
interned and can be treated as integers. If they were stored as strings there
would be no point in having them.
--
greg
