On 6/11/11 10:40 AM, Michel Fortin wrote:
On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
For representing categorical data with small sets, programming
languages use enumerated types. This is because in a small set you can
actually give name each element. That way you have a separate type for
the categorical data so you can enjoy good type checking. The mistake
I believe you are making is the conflation of a categorical data with
two categories with an unstructured Boolean. By making that conflation
you lose the advantages of good typechecking in one fell swoop.
I think you're misinterpreting. I don't like yes/no enums because I
don't find the value names meaningful, but I'm perfectly fine with
two-element enums if they are properly named.
What is meaningless about OpenRight.yes?
(But not all categorical data is a small set, and consequently
enumerated types are insufficient. Consider e.g. the notion of a user
id. People routinely use integers for that, and suffer endless
consequences because of bugs caused by unstructured integers posing as
user IDs. I have seen instances of such bugs in several codebases in
different languages.)
I totally agree with making specific types to avoid mixing unrelated
things, as long as it's reasonable. You wouldn't argue for a UserId type
if values of this type weren't passed around.
The problem is the definition of "reasonable" is loose. For all I can
tell we agree, it's just we have different notions of what's reasonable.
But boundaries can be open or closed on the right, but also on the left.
Unfortunately, because you choose to call the enum OpenRight, it can
only be used on the right, and nowhere else.
But this is intentional. If I wanted something more general, I would
have used something more general! What are you saying here?
What you're doing with OpenRight, and more generally with Flag!"", is
narrowing excessively the category to the point where it can be used at
one place and one place only: as a specific parameter to a specific
function. If you had another parameter for the left side, you'd create
an OpenLeft enum with exactly the same choices. I doubt this kind of
categorization has any advantage.
In fact, no. The same Flag instantiation can be used with distinct
functions. Its advantage is that you don't need to go out of your way
and define it. It's a sort of a lambda, a literal for a categorical value.
Actually, I think the advantage you seek has nothing to do with
categorization and much more to do with a desire to see those parameter
names appear at the call site. You're actually using over-categorization
to achieve that, and with Flag!"" you're going to make this systematic.
Sorry, I can't approve.
I think it's best to discuss the pros and cons of the proposal than the
proposer's desires. Yes, clarifying the intent at the call site is a
good thing. And yes, systematization can be good. Named parameters would
be one way to go about it, and categorization would be another. If you
characterize the approach as *over* categorization, I'm interested in
your justification of that qualification.
If you want to replace a bool with a two-option enum
at some places for clarity, that's fine. But I wouldn't elevate that to
a pattern meant to be used everywhere. And personally, I don't like the
proliferation of yes/no enums: if you use an enum, value names should be
more meaningful than a simple yes/no.
I think you'd be entirely wrong to make this distinction. There's
zero, one, and many. Not zero, one, two, and many.
No idea what you mean there.
Sets with zero and one elements have distinctive properties compared to
sets of more than one element. Sets with two elements don't.
Andrei
