Thread overview | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 23, 2016 What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Some ages ago, a whole suite of "assertPred" functions were written (giving better diagnostic info, like showing "expected vs actual"), were totally awesome, were submitted to phobos...and were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert". So...umm...yea...whatever happened to that beefed-up "assert" feature? |
September 23, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky wrote: > Some ages ago, a whole suite of "assertPred" functions were written (giving better diagnostic info, like showing "expected vs actual"), were totally awesome, were submitted to phobos...and were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert". > > So...umm...yea...whatever happened to that beefed-up "assert" feature? http://wiki.dlang.org/DIP83 (needs polishing and submission to the new dip process) |
September 23, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d wrote: > Some ages ago, a whole suite of "assertPred" functions were written (giving better diagnostic info, like showing "expected vs actual"), were totally awesome, were submitted to phobos...and were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert". > > So...umm...yea...whatever happened to that beefed-up "assert" feature? It was rejected: https://issues.dlang.org/show_bug.cgi?id=5547 Basically, the review that involved assertPred determined that it would be better to hav assert do it, but when someone tried to put in in the compiler, Walter rejected it, saying that it should be a library solution. There are also some potentially issues having assertions print out additional information in the case where the assertion is not in a unit test and there was concern over that. The big problem with assertPred though is that while it's really nice, it's also really expensive. All of those template instantions really added up. So, I don't know if it's ultimately a good idea or not, but I'd fully expect some of the unit testing libraries to have something similar, even if it's not anywhere near as fancy. - Jonathan M Davis |
September 23, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d
> wrote:
>>
>> So...umm...yea...whatever happened to that beefed-up "assert" feature?
>
> [...]
>
Ugh, so, "It was rejected for being library instead of assert, then it was rejected for being assert instead of library".
/facepalm
Guess I'll just have to try getting used to awful Java-isms like x.notEqual(y) :(
|
September 23, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 09/23/2016 11:47 PM, Nick Sabalausky wrote:
> On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote:
>> On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d
>> wrote:
>>>
>>> So...umm...yea...whatever happened to that beefed-up "assert" feature?
>>
>> [...]
>>
>
> Ugh, so, "It was rejected for being library instead of assert, then it
> was rejected for being assert instead of library".
>
> /facepalm
>
> Guess I'll just have to try getting used to awful Java-isms like
> x.notEqual(y) :(
And then that leads too, to the question of whether such third-party asserts are a good idea for the doc unittests I like so much... :/
|
September 24, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Friday, September 23, 2016 23:50:03 Nick Sabalausky via Digitalmars-d wrote: > On 09/23/2016 11:47 PM, Nick Sabalausky wrote: > > On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote: > >> On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d > >> > >> wrote: > >>> So...umm...yea...whatever happened to that beefed-up "assert" feature? > >> > >> [...] > > > > Ugh, so, "It was rejected for being library instead of assert, then it was rejected for being assert instead of library". > > > > /facepalm Indeed. :( > > Guess I'll just have to try getting used to awful Java-isms like > > x.notEqual(y) :( > > And then that leads too, to the question of whether such third-party asserts are a good idea for the doc unittests I like so much... :/ I'd say not. If you're writing a library for general consumption, I don't think that anyone else who is not actually helping to develop it should have to know or care what unit testing facilities you're using. assert is universal and clear, whereas other stuff is not universal and may or may not be clear to those not familiar with it. Also, my take on it is that ddoc-ed unittest blocks are really there to just give examples for the documentation, not to test your code. You want the examples tested so that you know that they work - which is why ddoc-ed unittest blocks are such a great feature - but it's not their purpose to test your library. It would be wholly unreasonable to have thorough tests in the documentation, and what makes a good example doesn't necessarily make for a very good test (or vice versa). So, you can just use basic assertions in your examples without really impacting your actual tests. You then have separate unittest blocks that have the full set of tests needed to verify full functionality, and those can use whatever unit testing tools you prefer without affecting anyone reading the documentation. - Jonathan M Davis |
September 24, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky wrote: > were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert". > > So...umm...yea...whatever happened to that beefed-up "assert" feature? assertPred!"=="(a, b); assertPred!"!"(a); assertPred!(std.range.equal)(a, b); Seems to do most of what DIP83 does w/ expensive feature design, and compiler implementation work. Also http://code.dlang.org/packages/unit-threaded comes with a couple of test comparators, though it follows ruby rspec's bad idea of giving every comparator a name (which has to be learnt and documented). |
September 24, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Saturday, September 24, 2016 08:03:15 Martin Nowak via Digitalmars-d wrote:
> On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky
>
> wrote:
> > were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert".
> >
> > So...umm...yea...whatever happened to that beefed-up "assert" feature?
>
> assertPred!"=="(a, b);
> assertPred!"!"(a);
> assertPred!(std.range.equal)(a, b);
>
> Seems to do most of what DIP83 does w/ expensive feature design,
> and compiler implementation work.
> Also http://code.dlang.org/packages/unit-threaded comes with a
> couple of test comparators, though it follows ruby rspec's bad
> idea of giving every comparator a name (which has to be learnt
> and documented).
assertPred as I had implemented it previously worked quite nicely except for the fact that it resulted in a fair bit of compiler overhead with all of the template stuff it was doing (I don't know how much that could be improved). As I recall, it was generally well-liked. It was just that some folks (Andrei included IIRC) thought that assert should be able to do at least the basics of what assertPred did automatically, which is why it was rejected. Since that time, there has been a greater push to do stuff in libraries where we can rather than to make the language do more, so maybe it would go over better today than it did then.
- Jonathan M Davis
|
September 24, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On 2016-09-24 00:02, Seb wrote: > http://wiki.dlang.org/DIP83 > > (needs polishing and submission to the new dip process) http://wiki.dlang.org/DIP50 :) -- /Jacob Carlborg |
September 24, 2016 Re: What's up with the assert enhancements proposed years ago? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 09/24/2016 06:52 AM, Jacob Carlborg wrote:
> On 2016-09-24 00:02, Seb wrote:
>
>> http://wiki.dlang.org/DIP83
>>
>> (needs polishing and submission to the new dip process)
>
> http://wiki.dlang.org/DIP50 :)
>
+1.
Although I haven't given it too much thought, I'd bet that could also be used to provide, in library, my #1 most wanted missing D feature: Input ranges (maybe even forward, too) written as stackless coroutines (C#-style, heck, even C can do it in lib). So we could write input ranges without turning the whole freaking algorithm completely inside-out, or requiring the overhead of a full fiber. Ever try doing LL parsing both traditional procedural-style and range-style? The range version's a complete unholy mess.
|
Copyright © 1999-2021 by the D Language Foundation