std.unittests [updated] for review

[Jonathan M Davis]

On Sunday 30 January 2011 06:10:25 Jens Mueller wrote:
> 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.

I guess that I just don't think of Exceptions and Errors as being all that 
different. They're both Throwables after all. True, you don't use them exactly 
the same way, but they're still very similar in purpose.

> > 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.

A lot of stuff comes down to preference and style, which is part of the problem. 
Far too often, you can't argue objectively about stuff like that, because too 
much of it is objective.

Personally, I wouldn't mind a hierarchy of modules in Phobos, and it wouldn't 
surprise me if we end up with one once we get enough modules, since tons of 
modules in a flat hierarchy is a bit unwieldy. However, I still don't like the 
idea of having a module with only 3 or 4 functions in it, which is the problem 
here.

- Jonathan M Davis