On Friday, August 27, 2010 11:05:46 SHOO wrote:
> (2010/08/28 2:25), Andrei Alexandrescu wrote:
> > I agree that AutoStart should be a module-level enum.
> > 
> > Andrei
> 
> AutoStart is a value only for StopWatch.
> I think that naturally it should belong to StopWatch.
> You can evade it in autoStart about the long-windedness.
> Is there any strong reason?

While I do agree that it might be nice to associate it more directly with StopWatch, putting it in the module should be clear enough. We already have it so that everything in a module has private access to the classes and structs within it, so modules are already somewhat coupled by their very nature. It really doesn't cost anything to stick it directly in the module, much as it would be ideal to have it directly associated with the struct. But then again, I never thought that just taking a bool was a problem. I understand why Andrei wants that sort of thing as an enum, and that's fine with me, but I don't really find it to be all that much better, personally. Regardless, we don't want them getting too verbose.

- Jonathan M Davis

(2010/08/28 2:23), David Simcha wrote:
> My bad.  For some reason I kept thinking StopWatch was a class.
>

In my opinion, I think that StopWatch does not have any problem in class. However, I think the default behavior to be AutoStart.no.

(2010/08/28 3:08), Andrei Alexandrescu wrote:
> On 8/27/10 11:05 PDT, SHOO wrote:
>> (2010/08/28 2:25), Andrei Alexandrescu wrote:
>>> I agree that AutoStart should be a module-level enum.
>>>
>>> Andrei
>>>
>>
>> AutoStart is a value only for StopWatch.
>> I think that naturally it should belong to StopWatch.
>> You can evade it in autoStart about the long-windedness.
>> Is there any strong reason?
>
> Just the verboseness.
>
> Andrei

I see. Because there was not particularly strong thought, I'll rewrite it.

On 8/27/10 11:26 PDT, Jonathan M Davis wrote:
> On Friday, August 27, 2010 11:05:46 SHOO wrote:
>> (2010/08/28 2:25), Andrei Alexandrescu wrote:
>>> I agree that AutoStart should be a module-level enum.
>>>
>>> Andrei
>>
>> AutoStart is a value only for StopWatch.
>> I think that naturally it should belong to StopWatch.
>> You can evade it in autoStart about the long-windedness.
>> Is there any strong reason?
>
> While I do agree that it might be nice to associate it more directly with StopWatch, putting it in the module should be clear enough. We already have it so that everything in a module has private access to the classes and structs within it, so modules are already somewhat coupled by their very nature. It really doesn't cost anything to stick it directly in the module, much as it would be ideal to have it directly associated with the struct. But then again, I never thought that just taking a bool was a problem. I understand why Andrei wants that sort of thing as an enum, and that's fine with me, but I don't really find it to be all that much better, personally. Regardless, we don't want them getting too verbose.

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.


Andrei

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

On Fri, Aug 27, 2010 at 4:00 PM, Jonathan M Davis <jmdavisprog at gmail.com>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
> phobos at puremagic.com
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100827/dd3f98e1/attachment.html>

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 <dsimcha at gmail.com> wrote:

> On Fri, Aug 27, 2010 at 4:00 PM, Jonathan M Davis <jmdavisprog at gmail.com>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
>> phobos at puremagic.com
>> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100828/0ed6b848/attachment-0001.html>

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 <yebblies at gmail.com> 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 <dsimcha at gmail.com>
> wrote:
> On Fri, Aug 27, 2010 at 4:00 PM, Jonathan M Davis <jmdavisprog at gmail.com
> > 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
> phobos at puremagic.com
> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100828/c0a21995/attachment.html>