Flag proposal

[Andrei Alexandrescu]

On 6/11/11 10:40 AM, Michel Fortin wrote:
> On 2011-06-11 09:56:28 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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