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

[Jens Mueller]

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.

Jens