std.unittests [updated] for review

[Jens Mueller]

Jonathan M Davis wrote:
> On Sunday 30 January 2011 05:13:19 Jens Mueller wrote:
> > 
> > My preference for distinct modules follows that line of separating
> > errors and exceptions.
> > The only argument against putting in its own module is it's size. That
> > seems to be your main point. I think putting something in new module
> > should mainly be concerned with separating stuff logically. Later on it
> > should be easy to add a new module that imports std.exception and let's
> > say std.assertion.
> > But all you say is valid. I just fear that fixing names later will be
> > costly. Having two modules allows us to handle this better. Just because
> > std.exception is already kind of messy doesn't justify putting in
> > there.
> 
> I think that it makes perfect sense for the likes of assertPred and assertThrown 
> to be in the same module as enforce. They serve similar functions. It's just 
> that one throws an assertError on failure, whereas the other usually throws an 
> Exception.

Somehow I'm a bit off here. Because assert throws an error and enforce
an exception make them not similar for me. I mean that's the whole point
of distinguishing error and exceptions.

> What is odd is sticking them in a module named std.exception. But while 
> assertPred might be similar to enforce, it definitely wouldn't make even less 
> sense to put enforce in a module named std.unittests. I have no idea what a good 
> name would be.

That's true. Since we do not have a good name for assert and enforce
together I wouldn't put them in the same module. I suppose there is a
reason why we are having difficulties finding a name.

> So, yes, it's a bit odd that std.exception would have assertPred in it, but it's 
> the best fit out of all of the pre-existing modules, and std.exception does have 
> semi-related functions. And honestly, I _do_ think that the size of a module 
> matters. If it doesn't have enough functions in it, then it really shouldn't be 
> its own module. The problem is when you have miscellaneous functions which don't 
> quite fit any any module - which may be why assumeUnique and pointsTo ended up in 
> std.exception.

For me it's first logical separation. This way I never end up with
functions in a module that do not belong there. But of course I may end
up with many modules. So I may end up with the same problem now with
modules. So I'm completely fine with hierarchies a la Java (maybe less
deep). I'll guess you're not.
I think of these modules as hierarchies as in a file system. Because
it's very for me to navigate in a file system.

No need to reply. I think you have good arguments that are valid. And in
the very end it often boils down to a matter of style. It's very
difficult to argue about style.

Jens