• Lionello Lunesu <lio lunesu.remove.com> Jun 12 2006
• Daniel Keep <daniel.keep.lists gmail.com> Jun 12 2006
• Lionello Lunesu <lio lunesu.remove.com> Jun 12 2006
• Deewiant <deewiant.doesnotlike.spam gmail.com> Jun 12 2006
• "Andrei Khropov" <andkhropov nospam_mtu-net.ru> Jun 12 2006
• "Boris Wang" <nano.kago hotmail.com> Jun 12 2006
• Lionello Lunesu <lio lunesu.remove.com> Jun 12 2006

Lionello Lunesu <lio lunesu.remove.com> writes:

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.

Daniel Keep <daniel.keep.lists gmail.com> writes:

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 <lio lunesu.remove.com> writes:

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 <deewiant.doesnotlike.spam gmail.com> writes:

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.

"Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:

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:




-- 
AKhropov

"Boris Wang" <nano.kago hotmail.com> writes:

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:




 -- 
 AKhropov
 

Lionello Lunesu <lio lunesu.remove.com> writes:

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:


 calling:




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.