[phobos] next release

[Jonathan M Davis]

On Thursday 09 September 2010 15:12:56 Andrei Alexandrescu wrote:
> On 9/9/10 16:47 CDT, Steve Schveighoffer wrote:
> > Alternatively, we can have std.stopwatch not appear in the docs until we
> > are certain of its location.
> 
> Then why add it? Most surely there won't be a module std.stopwatch.
> 
> > I think not including it is not a good idea.  Going by that philosophy,
> > we will have to wait until all date/time stuff is done before it's
> > included.
> 
> I'm talking about a minor release - a month.
> 
> > Another alternative is to call it std.xstopwatch until it's not
> > experimental anymore.  At least it will be easy to search/replace later.
> > 
> > Basically what we need is a mechanism to convey to the user that things
> > aren't set in stone for stopwatch.  Although are we making that
> > guarantee anywhere else?  I think through the last few releases, phobos
> > has had breaking changes (input ranges' save function comes to mind).
> 
> std.stopwatch is a simple artifact with a simple charter. I don't think
> we need to overengineer this.
> 
> 
> Andrei

Just so you know, I fully expect that the datetime code that I've been working 
on will be done in less than a month. It'll be at least a week (probably closer 
to two), but it certainly won't be in the range of a month. Now, how many 
changes will be required after it's reviewed, or whether it will be accepted at 
all, is another matter. But it shouldn't be all that much longer before I'm 
done.

Personally, I don't see any problem in having stopwatch in std.datetime. My code 
will certainly make for a large module in terms of the number of bytes that it 
is, but a large portion of that is unit tests and documentation. I would fully 
expect that in the long run other modules such as std.container will be far 
larger in terms of the number of types and functions in it (I have no idea about 
the size of the file though - I have a lot of unit tests). I would expect that 
stopwatch could fit in there just fine. Certainly, I don't see anywhere is that 
it's going to go under the current scheme.

It may be, however, that we're going to have to break down and allow some sort 
of package hierarchy at some point rather than having everything directly in 
std. Still, I don't know that we'd want a module like stopwatch which is 
essentially for one struct. If we end up with many single-purpose modules like 
that though, I think that we're definitely going to want some sort of module 
hierchary for at least some of them.

Regardless, I'd say that we want to avoid creating modules - or any code in 
general for that matter - which is not likely to stick around for long. It would 
likely be better practice to either figure out exactly where it's going to go and 
put it there or to simply have it not listed in the online docs until it is 
where it's likely to be permanently.

- Jonathan M Davis