On 6/11/11 8:16 AM, Michel Fortin wrote:
On 2011-06-11 07:54:58 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
Consider two statements:
1. "I dislike Flag. It looks ugly to me."
2. "I dislike Flag. Instead I want named arguments."
There is little retort to (1) - it simply counts as a vote against.
For (2) the course of action is to point out the liabilities of
changing the language.
I'm actually not sure whether I want named arguments or not, but I'm
quite sure I don't want to use Flag!"" in my code. I'd actually prefer a
simple bool parameter to Flag!"".
Currently, it looks like we have these possibilities:
// definition // call with a constant
void func(bool abc); -> func(true);
The call entails simple data coupling as documented by Steve McConnell:
you can pass any unstructured Boolean for any meaning of abc.
enum Abc { no, yes }
void func(Abc abc); -> func(Abc.yes);
To add the documentation effort:
/**
This is an argument for func. Refer to func below.
*/
enum Abc {
no, /// you don't want func to do Abc
yes /// you do want func to do Abc
}
/**
This is func. Mind Abc defined above.
*/
void func(Abc abc);
I think we agree this is rather awkward (I know because I wrote a fair
amount of such).
So we have the advantage of a nice call syntax and the disadvantage of
verbose definition and documentation.
void func(Flag!"Abc" abc); -> func(Flag!"Abc".yes);
-> func(yes!"Abc");
-> func(Yes.Abc);
which then becomes this if you're using a boolean expression instead of
a constant:
Aha! This reasoning is flawed as I'll explain below.
// definition // call with an expression
void func(bool abc); -> func(expression);
enum Abc { no, yes }
void func(Abc abc); -> func(expression ? Abc.yes : Abc.no);
-> func(cast(Abc)expression);
void func(Flag!"Abc" abc); -> func(expression ? Flag!"Abc".yes :
Flag!"Abc".no);
-> func(expression ? yes!"Abc" : no!"Abc");
-> func(expression ? Yes.Abc : No.Abc);
-> func(cast(Flag!"Abc")expression);
My take on this is that we shouldn't try to reinvent the boolean in the
standard library.
I think this characterization is wrong. Let me replace the meaningless
Abc with an actual example, e.g. OpenRight in std.algorithm.
OpenRight is not a Boolean. Its *representation* is Boolean. It is
categorical data with two categories. You can represent it with an
unstructured Boolean the same way you can represent an automaton state
with an unstructured integer or temperature with an unstructured double,
but then you'd have the disadvantages that dimensional analysis
libraries are solving.
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.
(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.)
As a direct consequence, it is *wrong* to desire to pass an unstructured
Boolean expression in lieu of OpenRight. So it is *good* that you can't.
What you *should* be doing is to define an OpenRight value in the first
place and use it, or construct it in place with "expr ? OpenRight.yes :
OpenRight.no", with the advantage that the conversion intent is explicit
and visible.
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.
Andrei
