I'm cutting back on the use of "bool" as a function parameter, since the words "true" and "false" are rarely applicable to the respective parameter, for example:

#void Invalidate( bool redraw );

This declaration seems ok, but when reading the code:

#Invalidate(true);

you have no idea what that "true" is referring to. I guess everybody knows what I'm talking about with "cutting back on the bool".

Obviously "enum" is the right replacement:

#enum redraw_t {
#  no_redraw = 0,	// false
#  redraw		// true
#}
#void Invalidate( redraw_t redraw );
#Invalidate( redraw_t.redraw );

Although nice, it adds quite a lot of overhead. What if you could declare the enum inline:

#void Invalidate( enum{no_redraw,redraw} );	// anonymous enum
#Invalidate( redraw );

Or, in case you want to be able to declare variables of the enum type:

#void Invalidate( enum redraw_t{no_redraw,redraw} );
#Invalidate( redraw_t.redraw );

This has the added benefit of being self documenting: you don't have to look-up the values of the enum, they are right there in the function definition.

Thoughts?

L.

Hmm... it would certainly help to make code more legible (which is always a good thing).  The only problem I can think of is that it can make function declarations somewhat long.  It's not too bad with only two members, but once you go beyond that, it gets a bit verbose:

# void Invalidate(enum redraw_t{default,no_redraw,redraw} redraw)

However, I think it's somewhat non-obvious what the scope of the enumeration is.  Do you make it a member of the function:

# Invalidate.redraw_t.no_redraw

Or the surrounding module scope?  In that case, do you allow multiple definitions?

I think that this would only really be desirable where you want to use
more meaningful names than true and false (otherwise it just clutters up
the function definition, and you'd likely just use a normal enum anyway)
to clear up exactly what that argument means.  But as you said, it's
also self-documenting... although I think that decent docs and/or an
editor that let you jump to the enum's definition would work just as well.

Still, interesting idea :)

Anonymous inline enum

# void Invalidate(enum redraw_t{no_redraw,redraw} redraw);
#
# Invalidate(redraw_t.redraw); // or...
# Invalidate(Invalidate.redraw_t.redraw);

Named inline enum

# void Invalidate(enum{no_redraw,redraw} redraw);
#
# Invalidate(redraw); // or...
# Invalidate(Invalidate.redraw); // or...
# Invalidate(.redraw); // ??? :P

Regular enum and fries

# enum redraw_t {
#     no_redraw,
#     redraw
# }
# void Invalidate(redraw_t redraw = redraw_t.no_redraw);
#
# Invalidate(redraw_t.redraw);

Using a typedef because I'm a lazy bugger who hates having to type "redraw_t." all the time :P

# typedef bool redraw_t;
# const no_redraw = cast(redraw_t)false;
# const redraw = cast(redraw_t)true;
#
# void Invalidate(redraw_t redraw = no_redraw);
#
# Invalidate(redraw);

Any other ways of writing this that might be nicer?

	-- Daniel

Lionello Lunesu wrote:
> I'm cutting back on the use of "bool" as a function parameter, since the words "true" and "false" are rarely applicable to the respective parameter, for example:
> 
> #void Invalidate( bool redraw );
> 
> This declaration seems ok, but when reading the code:
> 
> #Invalidate(true);
> 
> you have no idea what that "true" is referring to. I guess everybody knows what I'm talking about with "cutting back on the bool".
> 
> Obviously "enum" is the right replacement:
> 
> #enum redraw_t {
> #  no_redraw = 0,    // false
> #  redraw        // true
> #}
> #void Invalidate( redraw_t redraw );
> #Invalidate( redraw_t.redraw );
> 
> Although nice, it adds quite a lot of overhead. What if you could declare the enum inline:
> 
> #void Invalidate( enum{no_redraw,redraw} );    // anonymous enum
> #Invalidate( redraw );
> 
> Or, in case you want to be able to declare variables of the enum type:
> 
> #void Invalidate( enum redraw_t{no_redraw,redraw} );
> #Invalidate( redraw_t.redraw );
> 
> This has the added benefit of being self documenting: you don't have to look-up the values of the enum, they are right there in the function definition.
> 
> Thoughts?
> 
> L.

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Lionello Lunesu wrote:
> I'm cutting back on the use of "bool" as a function parameter, since the words "true" and "false" are rarely applicable to the respective parameter, for example:
> 
> #void Invalidate( bool redraw );
> 
> This declaration seems ok, but when reading the code:
> 
> #Invalidate(true);
> 
> you have no idea what that "true" is referring to. I guess everybody knows what I'm talking about with "cutting back on the bool".
> 
> Obviously "enum" is the right replacement:

I'd prefer just being able to pass the names of function parameters when calling:

Invalidate(redraw : true);

There were probably some reasons why this isn't that simple (syntax ambiguities or non-consensus), but I'm too lazy to look them up. I'm fairly sure this has been discussed before, though.

On second thought I also think it should be limited to anonymous enums. This will get rid of the enum's namespace as well.

The feature should be easy to implement when done as an anonymous global enum, but then there's no type checking. It would be nice if the compiler could only allow the enum's values for that parameter, and maybe even vice-versa: to only allow the enum's values inside the function call.

What about parameter default values?
#void Invalidate( enum{no_redraw,redraw} =redraw );

L.

Deewiant wrote:

> Lionello Lunesu wrote:
> > I'm cutting back on the use of "bool" as a function parameter, since the words "true" and "false" are rarely applicable to the respective parameter, for example:
> > 
> > #void Invalidate( bool redraw );
> > 
> > This declaration seems ok, but when reading the code:
> > 
> > #Invalidate(true);
> > 
> > you have no idea what that "true" is referring to. I guess everybody knows what I'm talking about with "cutting back on the bool".
> > 
> > Obviously "enum" is the right replacement:
> 
> I'd prefer just being able to pass the names of function parameters when calling:
Yeah, I like the idea too. It's possible in Python.


-- 
AKhropov

It's a good feature, not only a solution for this problem.

"Andrei Khropov" <andkhropov@nospam_mtu-net.ru> ??????:e6jveg$2g4o$1@digitaldaemon.com...
> Deewiant wrote:
>
>> Lionello Lunesu wrote:
>> > I'm cutting back on the use of "bool" as a function parameter, since
>> > the
>> > words "true" and "false" are rarely applicable to the respective
>> > parameter, for example:
>> >
>> > #void Invalidate( bool redraw );
>> >
>> > This declaration seems ok, but when reading the code:
>> >
>> > #Invalidate(true);
>> >
>> > you have no idea what that "true" is referring to. I guess everybody knows what I'm talking about with "cutting back on the bool".
>> >
>> > Obviously "enum" is the right replacement:
>>
>> I'd prefer just being able to pass the names of function parameters when calling:
> Yeah, I like the idea too. It's possible in Python.
>
>
> -- 
> AKhropov
> 

Andrei Khropov wrote:
> Deewiant wrote:
> 
>> Lionello Lunesu wrote:
>>> I'm cutting back on the use of "bool" as a function parameter, since the
>>> words "true" and "false" are rarely applicable to the respective
>>> parameter, for example:
>>>
>>> #void Invalidate( bool redraw );
>>>
>>> This declaration seems ok, but when reading the code:
>>>
>>> #Invalidate(true);
>>>
>>> you have no idea what that "true" is referring to. I guess everybody
>>> knows what I'm talking about with "cutting back on the bool".
>>>
>>> Obviously "enum" is the right replacement:
>> I'd prefer just being able to pass the names of function parameters when
>> calling:
> Yeah, I like the idea too. It's possible in Python.

Python needs it also for being able to pass the parameters of a function in a different order.

Anyway, the two proposals are compatible and complementary, so they should be discussed in separate threads, I suppose :)

L.