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
