On 6/11/11 11:56 AM, Michel Fortin wrote:
On 2011-06-11 12:01:33 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:

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?

Choosing between "yes" and "no" is not meaningful. I'd rather choose
between "open" and "closed".

I don't see how "OpenRight.yes" is meaningless and "Openness.right" is meaningful.

Of course you'd have to pick a more fitting
name for the enum,

Name one.

preferably one that could work for all bounds, not
just the right one to make the category more useful.

Again, the charter of that particular category is only "open to the right".

Anyway, that was the first thing "grep yes std/*" found. Let's see the next one:

/**
Specifies whether the output of certain algorithm is desired in sorted
format.
 */
enum SortOutput {
    no,  /// Don't sort output
    yes, /// Sort output
}

This already is very unpleasant because "certain" is as imprecise as it gets. Plus one for Flag, I hope you agree.

Alright, so we have

void topNIndex(
    alias less = "a < b",
    SwapStrategy ss = SwapStrategy.unstable,
    Range, RangeIndex)(Range r, RangeIndex index,
        SortOutput sorted = SortOutput.no);

With Flag in tow, you'd delete SortOutput and you'd replace the definition with:

void topNIndex(
    alias less = "a < b",
    SwapStrategy ss = SwapStrategy.unstable,
    Range, RangeIndex)(Range r, RangeIndex index,
        Flag!"sortOutput" sorted = No.sortOutput);

Call:

auto a = [ 1, 2, 3 ];
topNIndex(a, Yes.sortOutput);

I understand you find the above meaningless and would advocate using a bool, which means:

topNIndex(a, true);

which would have even me running to the manual, and I wrote the darn thing.

With named parameters, we'd have something along the lines of:

topNIndex(a, sortOutput : true);

which is nice, but not present in the language (and I can tell after talking to Walter it won't be anytime soon).

With your choice of meaningful/less, you'd have something like:

enum HowToOutput { unsorted, sorted }
topNIndex(a, HowToOutput.sorted);

which is pretty much the same thing as yes/no, just more convoluted and less systematic. I mean you can't impose to yourself to choose any names except "yes" and "no" on account of them being meaningless.


Andrei

Reply via email to