Would user polls be useful? (Was: Re: std.unittests [updated] for review)

[Jonathan M Davis]

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