Nick Sabalausky wrote: > "Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message > news:mailman.405.1294111260.4748.digitalmar...@puremagic.com... > > Well, it's not possible to overload assert, so that sort of thing really > > doesn't > > work. You're kind of stuck with something JUnit-ish in terms of names, > > though > > assertCmp and assertOpCmp both take a string for the operator, so you > > don't have > > assertLessThan, assertGreaterThan, etc. And what's there uses lazy instead > > of > > string mixins, because it's cleaner that way. lazy does the job just fine. > > > > And even if you could overload assert, you'd likely run into the same sort > > of > > problems that come up when you try and overload constructors and the like > > and > > the parameters aren't different enough to allow you to do all of the > > overloads > > that you want to do. At least JUnit-like naming is clear, and you're only > > going > > to use it unit tests, so it's fairly confined. So, if it bothers you, at > > least it > > doesn't affect your actual program code. > > > > The actual name "assert" isn't really what I was getting at. I realize > that's not usable, and that's fine. What I meant was, for instance, your > documentatin includes the example: > > assertOpBinary!"+"(Foo(5), 7, Foo(12)); > > (Although it doesn't seem to compile for me...) That's quite a mess compared > to the following: > > assert(Foo(5) + 7 == Foo(12));
I had the same impression. But I think it should be there for consistency reasons. Because there is also assertOpOpAssign. But you're right in case of assertOpBinary I prefer writing assertEqual(Foo(5) + 7, Foo(12)); Becaues it's one line and it gives enough information for me. But this does not hold for assertOpOpAssign anymore. > That can currently be done, of course, but it's output on failure obviously > doesn't give as much useful information as assertOpBinary. > > I think a middle ground is needed. For instance, with the assert utils in my > SemiTwist D Tools library, you can do this: > > mixin(deferEnsure!(`Foo(12)`, `_ == Foo(5) + 7`)); > > And the output upon failure still gives you this information: > > Expression 'Foo(12)': > Expected: _ == Foo(5) + 7 > Actual: 999 > > And, though I haven't done so yet, that can be generalized to allow it to > display what Foo(5) evaluated to. Admittedly, there's lots of room for > improvement in my syntax there, but the point is that you write an actual > expression and still get all the same useful information. > > So, just as one off-the-top-of-my-head idea, your lib could have something > like: > > assertExpression(`#Foo(5)# + 7 == #Foo(12)#`); > > The # delimiters (or whatever system of delimiters would make sense) > indicate what sub-expression should be displayed, ex: > > Assert failed: [Foo(5) + 7 == Foo(12)] > Foo(5): 6 > Foo(12): 12 > > Or: > > assertExpression(q(a + 7 == b}, Foo(5), Foo(12)); > // (same output as before) > > The whole things may or may not need to be wrapped in a "mixin()", I don't > know. > > Ie, something like that. Sounds useful and could be added later. Jens