This idiom works but only for classes and small structs.
Sent by shouting through my showerhead.
On Aug 27, 2010, at 10:16 PM, Daniel Murphy <[email protected]> wrote:
I understand that using an enum is the normal phobos way to do this,
but would the following be acceptable?
auto sw = StopWatch().start();
I've used this design in C++ before. Would this be acceptable for D/
phobos?
On Sat, Aug 28, 2010 at 6:12 AM, David Simcha <[email protected]>
wrote:
On Fri, Aug 27, 2010 at 4:00 PM, Jonathan M Davis <[email protected]
> wrote:
On Friday 27 August 2010 11:42:54 Andrei Alexandrescu wrote:
> I think I mentioned this - the Timer class we use at work has
startup
> dictated by true/false. Most of the code I'm reviewing uses:
>
> Timer timer;
> timer.start();
>
> thus wasting a vertical line (precious) over the simpler but
confusing:
>
> Timer timer(true);
>
> Another example from real code:
>
> serialize(output, data, true, true);
>
> The first true means use Base64 encoding. The second means use
compression.
Oh, I get what you're saying, and I don't exactly think that you're
wrong. I
just think that in many cases, bool works just fine. You often have
to look up
the function anyway, so the added clarity isn't much, and the added
verboseness
can be irritating. Obviously it can become a problem if you have
multiple bools,
and using enums instead can improve clarity in many cases, so using
enums does
have its advantages. When it comes down to it, I don't really have
any problem
with using an enum, but I don't really have a problem with bool
either.
Honestly, I don't think that it ever would have occurred to me to
use anything
but an enum did you not propose that enums should be used instead in
Phobos.
In any case, I've been using the enum model in the date/time code
that I've been
writing, so you won't have to worry about stray bool parameters in
there.
- Jonathan M Davis
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
I generally prefer enums in public or package APIs (because they're
more descriptive and not that much more verbose), but bools in
module- or class/struct-private functions (because this way I don't
have to define yet another type that I'm only going to use in a few
places and not that many other people have to understand the code).
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos