On Tuesday 01 February 2011 06:44:56 Jens Mueller wrote: > Jonathan M Davis wrote: > > On Monday 31 January 2011 15:49:11 Jens Mueller wrote: > > > spir wrote: > > > > On 01/30/2011 01:13 PM, Jens Mueller wrote: > > > > >I do not like putting it in std.exception. Maybe the name > > > > >std.unittest is also not good. I would propose std.assert if assert > > > > >wasn't a keyword. [...] > > > > > > > > > I would_not_ expect helpers for writing > > > > > > > > >assertions (Assert_Error_) in a module named std.exception. > > > > > > > > Same for me. Find it strange. Would never search assertion helper > > > > funcs inside std.exception. Why not std.assertion? std.unittests > > > > would be fine if there were some more stuff in there, I mean not > > > > only assertions. Else, the obvious name imo is std.assertion. > > > > > > Nice. I just wonder what others think. > > > I'd like to start a poll > > > http://doodle.com/vn2ceenuvfwtx38e > > > In general are those polls useful? I mean there where some > > > discussions in the last time where a poll may help. git vs. hg. 80 vs. > > > 90 characters per line. If all arguments are on the table it can be > > > useful to have an opinion poll to finally settle the discussion. > > > > > > It may even be that I'm totally wrong here. But I think the module > > > naming needs to be done very careful. It's what a D newcomer needs to > > > grasp as easy as possible. Am I too picky? Somehow I care (too?) much > > > about names. > > > > I wouldn't actually be looking for "assertion helpers" anywhere. I might > > be looking for unit test helper, but I wouldn't be thinking about > > assertions at all, even if the unit test helpers threw AssertError like > > they do. But truth be told, I don't generally look for modules with a > > particular name unless I know what I'm looking for. I look at the list > > of modules and see which names seem like they'd have what I'd want. As > > such, std.unittests would make me think that the module held unit test > > stuff, whereas I really wouldn't know what to expect in std.assertion or > > std.exception at all - _especially_ std.assertion. > > When I hear std.assertion and std.exception then I assume that these > modules contain stuff for working with assertions and exceptions > respectively. Just the fact that I want to throw an exception makes me > go to std.exception to check out what's in there. > > > However, given the small number of unit test functions, it makes no sense > > for them to be their own module. So, I really don't think that > > std.unittests makes sense at this point. std.exception may not be the > > best name, but given what's currently in it, the unit testing functions > > fit in there reasonably well. So, the issue then is what to name > > std.exception if that name is not good enough. std.assertion makes no > > sense - particularly with enforce in there - and std.unittests doesn't > > work, because it's not just unit testing stuff in there. > > I really dislike the size argument. Because as a programmer I do not > care how big a module is in the first place. First I care about how to > find it. > If I have found it I may say: "Oh that's a little module". But that > usually doesn't bother me much. > And putting something in a module where it does not belong is not an > option. I think we agree on that since you would like to have a better > name for std.exception. > > Just checked: > std.bigint is quite small looking at it's documentation. std.complex as > well. std.demangle is very small. std.functional has seven functions. > std.getopt has one big function in it. std.uni is very small. There are > more I'll guess. It's not the size of a module that comes first when to > decide where to put something. > > > So, unless you can come up with a better name for std.exception with the > > idea that it's going to be holding my new functions along with what's > > already in there, I don't think that discussing names is going to mean > > much. From a contents standpoint, it does make sense that the stuff in > > std.exception and my stuff would be lumped together, and it does not > > make sense for my stuff to be in its own module at this point. There > > isn't enough of it, and since it fits well in std.exception, there's > > even less reason to create a new module for it. So, if a change is to be > > made, I think that it's going to have to be to the name of > > std.exception, and I can't think of a better name nor have I see a > > better name suggested. > > The poll is less about a good name. It should be more about where do you > expect things to be. And since I do not have a good name for a module > that contains exception and error handling I don't like putting both > things in a module with a bad name. Because it will be very difficult to > fix this later. Even adding functions to modules may cause compile > problems. I may have defined an assertPred already in one of my > modules. I created the poll in the hope for more feedback how others > relate to this issue. I'm very unsure how important these module naming > and hierarchy issues are. But I fear that it may be too late to fix > these later. But there is a thread about renaming/removing modules in > std. > The more people start using Phobos the less it will be possible to fix > these things. And I have the impression that there are more people using > it day to day. > But after all if you do not feel the pain maybe I'm too sensitive. > Andrei is also fine with it.
I don't think that std.exception is a great name, but I _do_ think that my unit testing functions fit in well with what's already there (save for pointsTo and assumeUnique - I have _no_ idea why those two are in there - probably because they don't actually fit in well anywhere). So, from the perspective of the _contents_ of the module, it makes sense to put them in there. The _name_ of the module isn't great, but I don't know what a better name would be. Perhaps the the old std.contracts name fits a bit better with the addition of functions like assertPred which can reasonably be used in contracts, but it's not like std.contracts is a great name either. Yes, we _could_ create a std.unittests with assertPred, assertThrown, and assertNotThrown in it, but they're similar enough to enforce that I do like the idea of them being in the same module as enforce. I'm open to putting my functions wherever makes the most sense, but I don't think that it's entirely clear where that would be. I do think that putting them in std.exception makes a fair bit of sense, and that's where Andrei thinks that they should go, so I think that that works just fine. - Jonathan M Davis
