March 08, 2012
On 3/8/12 2:38 AM, Tyler Jameson Little wrote:
> I would like to do something like this:
>
> version (linux || BSD) {
> // do something...
> } else {
> version (Windows) {
> // do something else
> } else {
> // do something else
> assert(false, "Unsupported operating system");
> }
> }
>
> The only way I've been able to do this, is by splitting up the two
> versions and repeat code.
>
> Is there a better way to do this? A static if can do this, so is there a
> way that I can use a static if somehow?

I don't think it would be hard to implement boolean logic inside version.

Would it make sense if I make a pull request for it?

(because every now and then somebody stumbles upon this issue, and it looks like it could be implemented really easily)
March 08, 2012
On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote: [...]
> I don't think it would be hard to implement boolean logic inside version.

It's not hard at all.


> Would it make sense if I make a pull request for it?

Walter would reject it.

He has stated clearly in the past that he intended version to be
simple and minimal, and that adding anything onto it will only result in
abuses.


T

-- 
Why ask rhetorical questions? -- JC
March 09, 2012
On 3/8/12 6:11 PM, H. S. Teoh wrote:
> On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote:
> [...]
>> I don't think it would be hard to implement boolean logic inside
>> version.
>
> It's not hard at all.
>
>
>> Would it make sense if I make a pull request for it?
>
> Walter would reject it.
>
> He has stated clearly in the past that he intended version to be
> simple and minimal, and that adding anything onto it will only result in
> abuses.

What kind of abuses? I don't understand that logic in a language that allows you to use pointers, alloc memory however you want, and get segfaults for null memory access.
March 09, 2012
On Thu, Mar 08, 2012 at 10:25:53PM -0300, Ary Manzana wrote:
> On 3/8/12 6:11 PM, H. S. Teoh wrote:
> >On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote: [...]
> >>I don't think it would be hard to implement boolean logic inside version.
> >
> >It's not hard at all.
> >
> >
> >>Would it make sense if I make a pull request for it?
> >
> >Walter would reject it.
> >
> >He has stated clearly in the past that he intended version to be
> >simple and minimal, and that adding anything onto it will only result in
> >abuses.
> 
> What kind of abuses? I don't understand that logic in a language that allows you to use pointers, alloc memory however you want, and get segfaults for null memory access.

Ask Walter. It was his opinion.


T

-- 
People walk. Computers run.
March 09, 2012
On 03/09/2012 02:25 AM, Ary Manzana wrote:
> On 3/8/12 6:11 PM, H. S. Teoh wrote:
>> On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote:
>> [...]
>>> I don't think it would be hard to implement boolean logic inside
>>> version.
>>
>> It's not hard at all.
>>
>>
>>> Would it make sense if I make a pull request for it?
>>
>> Walter would reject it.
>>
>> He has stated clearly in the past that he intended version to be
>> simple and minimal, and that adding anything onto it will only result in
>> abuses.
>
> What kind of abuses?

Just have a look at reasonably portable C libraries that use the C preprocessor for versioning. IIRC Walter pointed to the Hans-Boehm GC the last time this issue was brought up.

> I don't understand that logic in a language that
> allows you to use pointers, alloc memory however you want, and get
> segfaults for null memory access.

Sorry, but this does not make any sense.
March 09, 2012
I have a felling people will end up abusing string mixins to generate version statements, and this will be the exact opposite effect Walter wanted. The same story goes for unittests which can't be independently ran to get a list of all failing unittests, and so people are coming up with their own custom unittest framework (e.g. the Orange library).
March 13, 2012
On 03/09/2012 06:20 AM, Andrej Mitrovic wrote:

> The same story goes for unittests which can't be independently
> ran to get a list of all failing unittests

D unittest blocks are for code correctness (as opposed to other meanings of the unfortunately overused term "unit testing" e.g. the functional testing of the end product). From that point of view, there should not be even a single test failing.

>, and so people are coming
> up with their own custom unittest framework (e.g. the Orange library).

Yes, some unit test features are missing. From my day-to-day use I would like to have the following:

- Ensure that a specific exception is thrown

- Test fixtures

That obviously reflects my use of unit tests but I really don't care how many tests are failing. The reason is, I start with zero failures and I finish with zero failures. Any code that breaks an existing test is either buggy or exposes an issue with the test, which must be dealt with right then.

Ali

March 13, 2012
On 3/13/12 2:21 PM, Ali Çehreli wrote:
> On 03/09/2012 06:20 AM, Andrej Mitrovic wrote:
>
>  > The same story goes for unittests which can't be independently
>  > ran to get a list of all failing unittests
>
> D unittest blocks are for code correctness (as opposed to other meanings
> of the unfortunately overused term "unit testing" e.g. the functional
> testing of the end product). From that point of view, there should not
> be even a single test failing.
>
>  >, and so people are coming
>  > up with their own custom unittest framework (e.g. the Orange library).
>
> Yes, some unit test features are missing. From my day-to-day use I would
> like to have the following:
>
> - Ensure that a specific exception is thrown
>
> - Test fixtures
>
> That obviously reflects my use of unit tests but I really don't care how
> many tests are failing. The reason is, I start with zero failures and I
> finish with zero failures. Any code that breaks an existing test is
> either buggy or exposes an issue with the test, which must be dealt with
> right then.
>
> Ali
>

How can you re-run just a failing test? (without having to run all the previous tests that will succeed?)
March 13, 2012
On 03/13/2012 11:04 AM, Ary Manzana wrote:
> On 3/13/12 2:21 PM, Ali Çehreli wrote:
>> On 03/09/2012 06:20 AM, Andrej Mitrovic wrote:
>>
>> > The same story goes for unittests which can't be independently
>> > ran to get a list of all failing unittests
>>
>> D unittest blocks are for code correctness (as opposed to other meanings
>> of the unfortunately overused term "unit testing" e.g. the functional
>> testing of the end product). From that point of view, there should not
>> be even a single test failing.
>>
>> >, and so people are coming
>> > up with their own custom unittest framework (e.g. the Orange library).
>>
>> Yes, some unit test features are missing. From my day-to-day use I would
>> like to have the following:
>>
>> - Ensure that a specific exception is thrown
>>
>> - Test fixtures
>>
>> That obviously reflects my use of unit tests but I really don't care how
>> many tests are failing. The reason is, I start with zero failures and I
>> finish with zero failures. Any code that breaks an existing test is
>> either buggy or exposes an issue with the test, which must be dealt with
>> right then.
>>
>> Ali
>>
>
> How can you re-run just a failing test? (without having to run all the
> previous tests that will succeed?)

I know that there are test suites too and Unittest++, the framework that we use, supports them but we don't use suites.

There has never been a need to run a subset of the tests for us. The tests almost by definition must run very fast anyway. We don't even notice that they get run automatically as a part of the build process.

We are getting a little off topic here but I've been following the recent unit test thread about writing to files. Unit tests should not have external interactions like that either. For example, no test should connect to an actual server to do some interaction. Developers wouldn't want that to happen every time a .d file is compiled. :) (Solutions like mocks, fakes, stubs, etc. do exist. And yes, I know that they are sometimes non-trivial.)

Ali

March 13, 2012
On 3/13/12, Ali Çehreli <acehreli@yahoo.com> wrote:
> Developers wouldn't
> want that to happen every time a .d file is compiled.

Well luckily unittests don't run when you compile a .d file but when you run the app! :)