View mode: basic / threaded / horizontal-split · Log in · Help
April 11, 2011
YesOrNo: useful idiom helper or wanking?
A fair amount of code in std uses this idiom:

enum SomeOption { no, yes }

void someFunction(...parms..., SomeOption, ...more_parms...) { ... }

SomeOption is really a Boolean but replaces the unhelpful call syntax 
someFunction(...args..., false, ...more_args...) with the 
self-documenting ...args..., SomeOption,no, ...more_args...).

The liabilities of using Booleans for describing flags have been 
documented in several places, including McConnell's Code Complete. I 
think the idiom above is a good replacement.

One issue I have with it is that it requires separate definition and 
documentation. Usually the documentation awkwardly states "This type is 
really an option for someFunction, which you haven't seen yet. Skip this 
for now, then get back, and you'll understand." Moving the enum to after 
the function is possible but equally confusing.

So I was thinking of planting a simple template in std.typecons:

template YesOrNo(string name)
{
    mixin("enum "~name~" : bool { no, yes }");
}

That way, the definition of the function needs no separately-defined is 
self-documenting:

void someFunction(...parms..., YesOrNo!"SomeOption", ...) { ... }

The question is to what extent this would mark progress and fostering 
structured use of this idiom, versus just confusing beginners and adding 
deadweight to Phobos.



Andrei
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
It looks like an awkward workaround for that feature called named arguments.
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
On 11.04.2011 16:53, Andrei Alexandrescu wrote:
> A fair amount of code in std uses this idiom:
> 
> enum SomeOption { no, yes }
> 
> void someFunction(...parms..., SomeOption, ...more_parms...) { ... }
> 
> SomeOption is really a Boolean but replaces the unhelpful call syntax
> someFunction(...args..., false, ...more_args...) with the
> self-documenting ...args..., SomeOption,no, ...more_args...).
> 
> The liabilities of using Booleans for describing flags have been
> documented in several places, including McConnell's Code Complete. I
> think the idiom above is a good replacement.
> 
> One issue I have with it is that it requires separate definition and
> documentation. Usually the documentation awkwardly states "This type is
> really an option for someFunction, which you haven't seen yet. Skip this
> for now, then get back, and you'll understand." Moving the enum to after
> the function is possible but equally confusing.
> 
> So I was thinking of planting a simple template in std.typecons:
> 
> template YesOrNo(string name)
> {
>     mixin("enum "~name~" : bool { no, yes }");
> }
> 
> That way, the definition of the function needs no separately-defined is
> self-documenting:
> 
> void someFunction(...parms..., YesOrNo!"SomeOption", ...) { ... }
> 
> The question is to what extent this would mark progress and fostering
> structured use of this idiom, versus just confusing beginners and adding
> deadweight to Phobos.
> 
> 
> 
> Andrei

Named parameters fix this without the need for workarounds.

someFunction(...parms..., someOption=>true, ...more parms....);
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
On 11.04.2011 18:53, Andrei Alexandrescu wrote:
> A fair amount of code in std uses this idiom:
>
> enum SomeOption { no, yes }
>
> void someFunction(...parms..., SomeOption, ...more_parms...) { ... }
>
> SomeOption is really a Boolean but replaces the unhelpful call syntax 
> someFunction(...args..., false, ...more_args...) with the 
> self-documenting ...args..., SomeOption,no, ...more_args...).
>
> The liabilities of using Booleans for describing flags have been 
> documented in several places, including McConnell's Code Complete. I 
> think the idiom above is a good replacement.
>
> One issue I have with it is that it requires separate definition and 
> documentation. Usually the documentation awkwardly states "This type 
> is really an option for someFunction, which you haven't seen yet. Skip 
> this for now, then get back, and you'll understand." Moving the enum 
> to after the function is possible but equally confusing.
>
> So I was thinking of planting a simple template in std.typecons:
>
> template YesOrNo(string name)
> {
>     mixin("enum "~name~" : bool { no, yes }");
> }
>
> That way, the definition of the function needs no separately-defined 
> is self-documenting:
>
> void someFunction(...parms..., YesOrNo!"SomeOption", ...) { ... }
>
> The question is to what extent this would mark progress and fostering 
> structured use of this idiom, versus just confusing beginners and 
> adding deadweight to Phobos.
>
>
Well, it's workaround but an interesting one.
I presume the user side remains intact and it's just enum declaration 
that got inculcated into the someFunction declaration, right? (I suspect 
some folks on the  NG might be puzzled by it so I'll try to clarify some 
points)
Like:
someFunction(...,SomeOption.yes,...);

Then yes it marks certain progress, and I like it. BTW double definition 
is also nicely solved (i.e. it would be the same template instance). 
YesOrNo!"Direction" would be the same for all function dealing with 
"Direction" parameter.

Then to save lives of novices reading API docs, we should have some nice 
short memo about this idiom on the language page or even in the Phobos 
module listing "common idioms" if we have lots of them, plus links to it 
everywhere applicable.

-- 
Dmitry Olshansky
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
Andrej Mitrovic wrote:
> It looks like an awkward workaround for that feature called named
> arguments.

Named arguments aren't a part of standard D now, nor does it look
likely they will be for many years.

We've gotta look at the here and now to make decisions; focus
on what we have rather than what we don't have.
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
They aren't a part of D as long as we try to avoid them with
workarounds that make functions look like crap.
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
On Apr 11, 11 23:27, Adam D. Ruppe wrote:
> Andrej Mitrovic wrote:
>> It looks like an awkward workaround for that feature called named
>> arguments.
>
> Named arguments aren't a part of standard D now, nor does it look
> likely they will be for many years.
>
> We've gotta look at the here and now to make decisions; focus
> on what we have rather than what we don't have.

Well the same argument was used to reject assertPred in favor of an 
improved assert which we still don't have (issue 5547). (Though changing 
assert's output doesn't change the D spec, while adding named arguments 
do, and the D2 spec is frozen.)
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
On 4/11/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> template YesOrNo(string name)
> {
>      mixin("enum "~name~" : bool { no, yes }");
> }
>
> void someFunction(YesOrNo!"SomeOption") { }

How exactly would this work? I can't compile it.
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
Also, I would rather name this template "choice". Maybe if people got
used to this word they would understand it when they see it in the
documentation before a function definition. E.g.:

http://codepad.org/9mrL6MOG or if the site is down:
https://gist.github.com/913926

Otherwise I have no idea how you can put a new type definition inside
of a function parameter and make it public? I'm kind of confused
here..
April 11, 2011
Re: YesOrNo: useful idiom helper or wanking?
On 11.04.2011 21:13, Andrej Mitrovic wrote:
> On 4/11/11, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> template YesOrNo(string name)
>> {
>>       mixin("enum "~name~" : bool { no, yes }");
>> }
>>
>> void someFunction(YesOrNo!"SomeOption") { }
> How exactly would this work? I can't compile it.
Yeah it's problematic, making it eponymous make function definition 
work, but at the calling site the party ends...

-- 
Dmitry Olshansky
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home