[cairo] Adding a boolean type
Owen Taylor
otaylor at redhat.com
Tue Feb 1 07:42:41 PST 2005
On Tue, 2005-02-01 at 10:11 -0500, Carl Worth wrote:
> On Tue, 01 Feb 2005 09:24:02 -0500, Owen Taylor wrote:
> > But not adding some sort of public TRUE/FALSE defines publically
> > seems sort of a half-measure. And are we going to remember to add
> > the defines if we add a usage of cairo_bool_t as a parameter?
>
> Ah, boolean parameters. I tend to dislike boolean parameters
> entirely. The problem is that code gets very hard to read, (and harder
> to write), when it has calls that look something like:
>
> some_function (..., TRUE, FALSE, TRUE); [*]
>
> To avoid them, I generally create enums, even when we "know" we only
> expect two possible choices. See, for example, cairo_fill_rule_t and
> cairo_font_weight_t. This makes the calling code much more
> self-documenting.
>
> It would be even better if the compilers were more strict about
> type-correctness when passing enums around. I can't seem to find a -W
> option in gcc to complain about that.
>
> -Carl
>
> [*] And, note that cairo also tries to avoid long parameter lists in
> general, which also helps alleviate this problem.
Don't those two things go in opposite directions? I could agree with
the statement "a function with more than two parameters should never
have boolean parameters". But something like:
gtk_color_button_set_use_alpha (color_button,
GTK_COLOR_BUTTON_NO_ALPHA);
feels pedantic. Anyways, if your confident of the lack of need for
boolean parameters in Cairo, I guess I can't object to omitting
cairo.h #defines for now.
Regards,
Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050201/1d2846a3/attachment.pgp
More information about the cairo
mailing list