Okay. On the whole, I'm fine with std.datetime being one, large module. It works fine from a maintenance standpoint, and while some people have complained about the large number of unit tests getting in the way of finding stuff in the file, I find that having the unit tests right next to the functions like that to really help with maintenance.

I do have one concern however. As there's a fair bit of functionality in there, there's a lot of documentation, and I'm afraid that the documentation may be a bit overwhelming to someone trying to figure out how to use std.datetime. On the whole, everything in there is quite easy to use, but there's a lot of it.

So, what I'm wondering is if it would be worthwhile to split out the interval and range stuff into a separate module. That wouldn't hugely reduce the size of the module, but it _would_ make the documentation more manageable. It also has the nice side effect that the three main date/time concepts would then be in three separate modules. The duration types were already split into core.time, because Sean needed a duration type for some stuff in druntime. The time points would stay in std.datetime. And the time intervals would then be in std.timeinterval (or whatever we wanted to call it). The documentation would therefore be more easily digestible. Also, if and when I get around to coming up with more date/time functionality, the main area that I'd likely be putting it would be in the intervals and ranges (in particular, at some point, I'd like to create functionality to handle date recurrence patterns), so the bulk of the new stuff would end up in the smaller of the two time-related modules in Phobos, thereby evening out their size a bit.

Again, I don't really have a problem with std.datetime being as big as it is (though some people do), but I _am_ concerned that the documentation is going to be a bit hard to digest for newcomers. It's not complicated, but there's a lot of it. So, I'm thinking that there would be some value in create std.timeinterval for the date/time interval and range functionality, thereby reducing the size of std.datetime and making it easier for newcomers to digest. It will also make it easier to find the interval and range-related functionality if that's what you're looking for.

So, what are everyone else's thoughts on this? Andrei and Walter favored std.datetime being one giant module, and I don't exactly disagree, but I do think that splitting _some_ of its functionality out would make it more digestible, and I know that there are at least a few folks who think that std.datetime is just plain too large.

- Jonathan M Davis

On Wed, 2011-02-09 at 21:54 -0800, Jonathan M Davis wrote:
> Okay. On the whole, I'm fine with std.datetime being one, large module. It works fine from a maintenance standpoint, and while some people have complained about the large number of unit tests getting in the way of finding stuff in the file, I find that having the unit tests right next to the functions like that to really help with maintenance.
> 
> I do have one concern however. As there's a fair bit of functionality in there, there's a lot of documentation, and I'm afraid that the documentation may be a bit overwhelming to someone trying to figure out how to use std.datetime. On the whole, everything in there is quite easy to use, but there's a lot of it.
> 
> So, what I'm wondering is if it would be worthwhile to split out the interval and range stuff into a separate module. That wouldn't hugely reduce the size of the module, but it _would_ make the documentation more manageable. It also has the nice side effect that the three main date/time concepts would then be in three separate modules. The duration types were already split into core.time, because Sean needed a duration type for some stuff in druntime. The time points would stay in std.datetime. And the time intervals would then be in std.timeinterval (or whatever we wanted to call it). The documentation would therefore be more easily digestible. Also, if and when I get around to coming up with more date/time functionality, the main area that I'd likely be putting it would be in the intervals and ranges (in particular, at some point, I'd like to create functionality to handle date recurrence patterns), so the bulk of the new stuff would end up in the smaller of the two time-related modules in Phobos, thereby evening out their size a bit.
> 
> Again, I don't really have a problem with std.datetime being as big as it is (though some people do), but I _am_ concerned that the documentation is going to be a bit hard to digest for newcomers. It's not complicated, but there's a lot of it. So, I'm thinking that there would be some value in create std.timeinterval for the date/time interval and range functionality, thereby reducing the size of std.datetime and making it easier for newcomers to digest. It will also make it easier to find the interval and range-related functionality if that's what you're looking for.
> 
> So, what are everyone else's thoughts on this? Andrei and Walter favored std.datetime being one giant module, and I don't exactly disagree, but I do think that splitting _some_ of its functionality out would make it more digestible, and I know that there are at least a few folks who think that std.datetime is just plain too large.

I don't think std.datetime should be split.  Keeping it in one file is consistent with the way the other Phobos modules are organised.  Rather, the Phobos documentation as a whole (and possibly DDOC itself) should be improved.

If it were to be split, I think it would be better to split it into
std.calendar (Date, TimeOfDay, DateTime), and std.time (SysTime,
StopWatch).

Note that I'm not saying I think Phobos' flat module hierarchy is the best one.  On the contrary, now that the library is getting so big, it would probably be better to have it one level deeper (std.algorithm.search, std.algorithm.sort, std.time.calendar, std.time.systime, etc.), but I guess it's too late for that.

-Lars

On Thursday 10 February 2011 01:49:24 Lars Tandle Kyllingstad wrote:
> On Wed, 2011-02-09 at 21:54 -0800, Jonathan M Davis wrote:
> > Okay. On the whole, I'm fine with std.datetime being one, large module. It works fine from a maintenance standpoint, and while some people have complained about the large number of unit tests getting in the way of finding stuff in the file, I find that having the unit tests right next to the functions like that to really help with maintenance.
> > 
> > I do have one concern however. As there's a fair bit of functionality in there, there's a lot of documentation, and I'm afraid that the documentation may be a bit overwhelming to someone trying to figure out how to use std.datetime. On the whole, everything in there is quite easy to use, but there's a lot of it.
> > 
> > So, what I'm wondering is if it would be worthwhile to split out the interval and range stuff into a separate module. That wouldn't hugely reduce the size of the module, but it _would_ make the documentation more manageable. It also has the nice side effect that the three main date/time concepts would then be in three separate modules. The duration types were already split into core.time, because Sean needed a duration type for some stuff in druntime. The time points would stay in std.datetime. And the time intervals would then be in std.timeinterval (or whatever we wanted to call it). The documentation would therefore be more easily digestible. Also, if and when I get around to coming up with more date/time functionality, the main area that I'd likely be putting it would be in the intervals and ranges (in particular, at some point, I'd like to create functionality to handle date recurrence patterns), so the bulk of the new stuff would end up in the smaller of the two time-related modules in Phobos, thereby evening out their size a bit.
> > 
> > Again, I don't really have a problem with std.datetime being as big as it is (though some people do), but I _am_ concerned that the documentation is going to be a bit hard to digest for newcomers. It's not complicated, but there's a lot of it. So, I'm thinking that there would be some value in create std.timeinterval for the date/time interval and range functionality, thereby reducing the size of std.datetime and making it easier for newcomers to digest. It will also make it easier to find the interval and range-related functionality if that's what you're looking for.
> > 
> > So, what are everyone else's thoughts on this? Andrei and Walter favored std.datetime being one giant module, and I don't exactly disagree, but I do think that splitting _some_ of its functionality out would make it more digestible, and I know that there are at least a few folks who think that std.datetime is just plain too large.
> 
> I don't think std.datetime should be split.  Keeping it in one file is consistent with the way the other Phobos modules are organised.  Rather, the Phobos documentation as a whole (and possibly DDOC itself) should be improved.
> 
> If it were to be split, I think it would be better to split it into
> std.calendar (Date, TimeOfDay, DateTime), and std.time (SysTime,
> StopWatch).
> 
> Note that I'm not saying I think Phobos' flat module hierarchy is the best one.  On the contrary, now that the library is getting so big, it would probably be better to have it one level deeper (std.algorithm.search, std.algorithm.sort, std.time.calendar, std.time.systime, etc.), but I guess it's too late for that.

Splitting along the major concepts - time points, time intervals, and durations - makes a lot of sense to me. The time point code doesn't need to care about the internals of the durations that it uses, and the time interval code doesn't need to care about the internals of the durations or the time points that it uses, but some of the D types in each of the three categories need to know about the other D types in the same category. So doing something like splitting SysTime from Date, TimeOfDay, and DateTime wouldn't work very well. Also, conceptually, I don't think that that it makes sense to separate them precisely because they're all time points and thus very similar. Not to mention, while Date, TimeOfDay, and DateTime are designed with calendar-based uses in mind, SysTime has all of the same functions so that you can use _it_ for a calendar solution just fine. It's just less efficient for that due to its internal representation, and you do have a time zone with it, which may or may not be what you want for calendar-based stuff. But from an API perspective, DateTime and SysTime are very similar. It's mostly a difference in representation and therefore efficiency. Regardless, the various time types are all similar enough that splitting them up doesn't really make sense IMO.

Time intervals on the other hand just _use_ time points and durations, so they _can_ be put in a separate module quite cleanly. It's kind of like the difference between std.range and std.algorithm. For the most part, std.range deals with defining range stuff whereas std.algorithm uses the range stuff. They're related but separate.

As for improving the documentation, I've been working on that, but you can't separate it out without separating the code into separate modules. It makes a lot of sense to me to have the time intervals separate. That reduces how much documentation is on the one page for std.datetime, and it makes it _much_ easier to sort out and find the interval and range types and functions. But without dividing the module, you can't divide the documentation - not with how ddoc currently works.

Like the Boost date/time stuff, our date/time stuff is built around the concepts of time points, time durations, and time intervals. And I think that it makes good sense to split the module along those lines. I already had to split out the duration stuff into core.time so that druntime could use it. If I split out the time interval stuff into a separate module, then each of the three base concepts is separated out into its own module, and it makes looking up their related types and functions much easier IMHO.

So, I'm not looking to just break up std.datetime willy-nilly or just to reduce it's size. I think that it makes a lot of sense to split it based on its core concepts. _That_ makes it much easier to find what you're looking for in it. It would _also_ reduce the size of std.datetime's documentation, but the interval and range stuff is a small enough percentage of the module, that it's not like the reduction would be much from the standpoint of the amount of text. It _would_ however reduce the number of concepts that the std.datetime documentation would have to worry about.

- Jonathan M Davis

On Thu, 2011-02-10 at 02:14 -0800, Jonathan M Davis wrote:
> On Thursday 10 February 2011 01:49:24 Lars Tandle Kyllingstad wrote:
> > On Wed, 2011-02-09 at 21:54 -0800, Jonathan M Davis wrote:
> > > [...]
> > > So, what are everyone else's thoughts on this? Andrei and Walter favored
> > > std.datetime being one giant module, and I don't exactly disagree, but I
> > > do think that splitting _some_ of its functionality out would make it
> > > more digestible, and I know that there are at least a few folks who
> > > think that std.datetime is just plain too large.
> > 
> > I don't think std.datetime should be split.  Keeping it in one file is consistent with the way the other Phobos modules are organised.  Rather, the Phobos documentation as a whole (and possibly DDOC itself) should be improved.
> > 
> > [...]

> Splitting along the major concepts - time points, time intervals, and durations - makes a lot of sense to me. The time point code doesn't need to care about the internals of the durations that it uses, and the time interval code doesn't need to care about the internals of the durations or the time points that it uses, but some of the D types in each of the three categories need to know about the other D types in the same category. So doing something like splitting SysTime from Date, TimeOfDay, and DateTime wouldn't work very well. Also, conceptually, I don't think that that it makes sense to separate them precisely because they're all time points and thus very similar. Not to mention, while Date, TimeOfDay, and DateTime are designed with calendar-based uses in mind, SysTime has all of the same functions so that you can use _it_ for a calendar solution just fine. It's just less efficient for that due to its internal representation, and you do have a time zone with it, which may or may not be what you want for calendar-based stuff. But from an API perspective, DateTime and SysTime are very similar. It's mostly a difference in representation and therefore efficiency. Regardless, the various time types are all similar enough that splitting them up doesn't really make sense IMO.
> 
> Time intervals on the other hand just _use_ time points and durations, so they _can_ be put in a separate module quite cleanly. It's kind of like the difference between std.range and std.algorithm. For the most part, std.range deals with defining range stuff whereas std.algorithm uses the range stuff. They're related but separate.

Ok.  I should probably get more familiar with std.datetime before continuing the debate, lest I make a fool of myself. ;)


> As for improving the documentation, I've been working on that, but you can't
> separate it out without separating the code into separate modules. It makes a
> lot of sense to me to have the time intervals separate. That reduces how much
> documentation is on the one page for std.datetime, and it makes it _much_ easier
> to sort out and find the interval and range types and functions. But without
> dividing the module, you can't divide the documentation - not with how ddoc
> currently works.
> [...]

I don't necessarily think that the documentation for std.datetime (or any other large module) needs to be split over several pages.  My main gripes with the current documentation are:

1. The table of contents at the top sucks.  It's just one big lump of text, and it's impossible to see whether something is a free function, a member function, a type, an alias, an enum, etc.

2. The documentation only uses indentation to indicate the relationship between the different elements.  Look at the documentation for DateTime.fromISOString(), for instance.  You have to do a fair bit of scrolling to figure out whether it is a free function or a member function, and of which type it is a member.

3. It is not possible to impose any structure on the documentation, beyond the one given by the code.  In the recent discussion about the std.algorithm docs, Adam Ruppe suggested a Tag: section, so you could tag an std.algorithm function with 'searching', 'set operation', 'sorting', etc.  That would probably do wonders for std.datetime as well.

Fixing these issues would go a LONG way in improving the documentation. (And it seems Andrei and Adam have both been working on this lately.)

-Lars

On Thursday 10 February 2011 02:46:36 Lars Tandle Kyllingstad wrote:
> On Thu, 2011-02-10 at 02:14 -0800, Jonathan M Davis wrote:
> > On Thursday 10 February 2011 01:49:24 Lars Tandle Kyllingstad wrote:
> > > On Wed, 2011-02-09 at 21:54 -0800, Jonathan M Davis wrote:
> > > > [...]
> > > > So, what are everyone else's thoughts on this? Andrei and Walter
> > > > favored std.datetime being one giant module, and I don't exactly
> > > > disagree, but I do think that splitting _some_ of its functionality
> > > > out would make it more digestible, and I know that there are at
> > > > least a few folks who think that std.datetime is just plain too
> > > > large.
> > > 
> > > I don't think std.datetime should be split.  Keeping it in one file is consistent with the way the other Phobos modules are organised. Rather, the Phobos documentation as a whole (and possibly DDOC itself) should be improved.
> > > 
> > > [...]
> > 
> > Splitting along the major concepts - time points, time intervals, and durations - makes a lot of sense to me. The time point code doesn't need to care about the internals of the durations that it uses, and the time interval code doesn't need to care about the internals of the durations or the time points that it uses, but some of the D types in each of the three categories need to know about the other D types in the same category. So doing something like splitting SysTime from Date, TimeOfDay, and DateTime wouldn't work very well. Also, conceptually, I don't think that that it makes sense to separate them precisely because they're all time points and thus very similar. Not to mention, while Date, TimeOfDay, and DateTime are designed with calendar-based uses in mind, SysTime has all of the same functions so that you can use _it_ for a calendar solution just fine. It's just less efficient for that due to its internal representation, and you do have a time zone with it, which may or may not be what you want for calendar-based stuff. But from an API perspective, DateTime and SysTime are very similar. It's mostly a difference in representation and therefore efficiency. Regardless, the various time types are all similar enough that splitting them up doesn't really make sense IMO.
> > 
> > Time intervals on the other hand just _use_ time points and durations, so they _can_ be put in a separate module quite cleanly. It's kind of like the difference between std.range and std.algorithm. For the most part, std.range deals with defining range stuff whereas std.algorithm uses the range stuff. They're related but separate.
> 
> Ok.  I should probably get more familiar with std.datetime before continuing the debate, lest I make a fool of myself. ;)
> 
> > As for improving the documentation, I've been working on that, but you
> > can't separate it out without separating the code into separate modules.
> > It makes a lot of sense to me to have the time intervals separate. That
> > reduces how much documentation is on the one page for std.datetime, and
> > it makes it _much_ easier to sort out and find the interval and range
> > types and functions. But without dividing the module, you can't divide
> > the documentation - not with how ddoc currently works.
> > [...]
> 
> I don't necessarily think that the documentation for std.datetime (or any other large module) needs to be split over several pages.  My main gripes with the current documentation are:
> 
> 1. The table of contents at the top sucks.  It's just one big lump of text, and it's impossible to see whether something is a free function, a member function, a type, an alias, an enum, etc.
> 
> 2. The documentation only uses indentation to indicate the relationship between the different elements.  Look at the documentation for DateTime.fromISOString(), for instance.  You have to do a fair bit of scrolling to figure out whether it is a free function or a member function, and of which type it is a member.
> 
> 3. It is not possible to impose any structure on the documentation, beyond the one given by the code.  In the recent discussion about the std.algorithm docs, Adam Ruppe suggested a Tag: section, so you could tag an std.algorithm function with 'searching', 'set operation', 'sorting', etc.  That would probably do wonders for std.datetime as well.
> 
> Fixing these issues would go a LONG way in improving the documentation. (And it seems Andrei and Adam have both been working on this lately.)

Yes. Fixing stuff like the links at the top would definitely help. The docs are not currently setup to deal with classes and structs very well - the biggest offense being that the links act like _all_ functions are free-functions and can't handle the fact that there are multiple functions with the same name in the file - even when they're in separate structs or classes. The links really should group struct and class functions as part of their associated struct or class. But my issue here isn't so much that as the fact that time points and time intervals are distinct concepts that I'd like to be able partition.

In particular, what I find frustrating is that I would like to be able to section off the range-related functions and group them in an obvious and easy-to-find way. While they _are_ grouped in the file, you do have to do a bit of searching for them unless you already know what they're named. For the moment, the range- generating functions are all marked with "Generates a range-generating function for intervals" so that they're easily searchable (and the fwdRange and bwdRange functions on the interval types mention that), but that's kind of dumb IMO. It's just the best that I could think of thus far, short of splitting them out into a separate module. If the interval stuff and range stuff were in their own module, then it would all be clearly grouped. In dealing with time intervals and their associated ranges, it feels to me like they really should be separated from the rest of std.datetime - they use it, but they're definitely different from most of the rest of it (most of which focuses on time points). Time points and time intervals (and their associated ranges) are distinct concepts that I'd like to separate.

So, I'd like to split the interval and range-based stuff into its own module. I think that it would just plain be cleaner that way. But obviously, I'm not going to just move them into their own module without some sort of agreement on the matter from other Phobos developers.

- Jonathan M Davis

On 02/10/2011 10:49 AM, Lars Tandle Kyllingstad wrote:
> If it were to be split, I think it would be better to split it into
> std.calendar (Date, TimeOfDay, DateTime), and std.time (SysTime,
> StopWatch).

Makes sense for me. What about (Date, CLock, DateClock)? (some PL uses that, I like it)

> Note that I'm not saying I think Phobos' flat module hierarchy is the best one.  On the contrary, now that the library is getting so big, it would probably be better to have it one level deeper (std.algorithm.search, std.algorithm.sort, std.time.calendar, std.time.systime, etc.), but I guess it's too late for that.

+++ Too bad if it's too late. Another solution is namespaces inside modules (possibly created as fake abstract classes used as packs of functionality, for modules which mainly hold free funcs, enums, and such).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Le 2011-02-10 ? 0:54, Jonathan M Davis a ?crit :

> I do have one concern however. As there's a fair bit of functionality in there, there's a lot of documentation, and I'm afraid that the documentation may be a bit overwhelming to someone trying to figure out how to use std.datetime. On the whole, everything in there is quite easy to use, but there's a lot of it.

I agree that the documentation isn't very well structured; std.datetime is hardly the only module with this problem.

I disagree about restructuring the code if the goal is only to make the documentation better. The right solution is to improve the documentation generation, not to contort the code to fit a particular documentation structure. Let's ask ourself how we want the documentation to be, then lets look at how we can achieve that.

Creating a table of content sorted by task (like Andrei did for std.algorithm) looks like a good start. Another idea to address the nesting problem could be to collapse the nested declarations with a show/hide javascript button to avoid having nested declarations you don't know they belong to what (if you've explicitly disclosed some content, you should know what it is). Perhaps it'd also be nice if things could be split on multiple pages, but I'm not sure on what criterion.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 02/10/2011 02:03 PM, Michel Fortin wrote:
> Creating a table of content sorted by task (like Andrei did for std.algorithm) looks like a good start. Another idea to address the nesting problem could be to collapse the nested declarations with a show/hide javascript button to avoid having nested declarations you don't know they belong to what (if you've explicitly disclosed some content, you should know what it is).

Very similar to what I dream of: that the doc page is folded just like code in an editor or a directory tree, letting only headers visible. Then one can quickly browse it, see the dependancies (showed by indentation like now), and open sections at will to read the actual doc contents.

class Range +		<-- open doc for 'Range'
     bool empty() +	<-- open doc for 'empty'

[Actually, it's more or less reproducing python's doc structure in source (where the doc sections belong to what they describe, instead of beeing weirdly & unpractically placed before).]

>  Perhaps it'd also be nice if things could be split on multiple pages, but I'm
not sure on what criterion.

Rather not, I guess, would increase the complexity.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 10 feb 2011, at 10:49, Lars Tandle Kyllingstad wrote:

> On Wed, 2011-02-09 at 21:54 -0800, Jonathan M Davis wrote:
>> Okay. On the whole, I'm fine with std.datetime being one, large module. It works fine from a maintenance standpoint, and while some people have complained about the large number of unit tests getting in the way of finding stuff in the file, I find that having the unit tests right next to the functions like that to really help with maintenance.
>> 
>> I do have one concern however. As there's a fair bit of functionality in there, there's a lot of documentation, and I'm afraid that the documentation may be a bit overwhelming to someone trying to figure out how to use std.datetime. On the whole, everything in there is quite easy to use, but there's a lot of it.
>> 
>> So, what I'm wondering is if it would be worthwhile to split out the interval and range stuff into a separate module. That wouldn't hugely reduce the size of the module, but it _would_ make the documentation more manageable. It also has the nice side effect that the three main date/time concepts would then be in three separate modules. The duration types were already split into core.time, because Sean needed a duration type for some stuff in druntime. The time points would stay in std.datetime. And the time intervals would then be in std.timeinterval (or whatever we wanted to call it). The documentation would therefore be more easily digestible. Also, if and when I get around to coming up with more date/time functionality, the main area that I'd likely be putting it would be in the intervals and ranges (in particular, at some point, I'd like to create functionality to handle date recurrence patterns), so the bulk of the new stuff would end up in the smaller of the two time-related modules in Phobos, thereby evening out their size a bit.
>> 
>> Again, I don't really have a problem with std.datetime being as big as it is (though some people do), but I _am_ concerned that the documentation is going to be a bit hard to digest for newcomers. It's not complicated, but there's a lot of it. So, I'm thinking that there would be some value in create std.timeinterval for the date/time interval and range functionality, thereby reducing the size of std.datetime and making it easier for newcomers to digest. It will also make it easier to find the interval and range-related functionality if that's what you're looking for.
>> 
>> So, what are everyone else's thoughts on this? Andrei and Walter favored std.datetime being one giant module, and I don't exactly disagree, but I do think that splitting _some_ of its functionality out would make it more digestible, and I know that there are at least a few folks who think that std.datetime is just plain too large.
> 
> I don't think std.datetime should be split.  Keeping it in one file is consistent with the way the other Phobos modules are organised.  Rather, the Phobos documentation as a whole (and possibly DDOC itself) should be improved.
> 
> If it were to be split, I think it would be better to split it into
> std.calendar (Date, TimeOfDay, DateTime), and std.time (SysTime,
> StopWatch).
> 
> Note that I'm not saying I think Phobos' flat module hierarchy is the best one.  On the contrary, now that the library is getting so big, it would probably be better to have it one level deeper (std.algorithm.search, std.algorithm.sort, std.time.calendar, std.time.systime, etc.), but I guess it's too late for that.
> 

I agree with this, we need to start to create packages and not just have a flat module hierarchy

> -Lars
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

On 10 feb 2011, at 11:46, Lars Tandle Kyllingstad wrote:
> I don't necessarily think that the documentation for std.datetime (or any other large module) needs to be split over several pages.  My main gripes with the current documentation are:
> 
> 1. The table of contents at the top sucks.  It's just one big lump of text, and it's impossible to see whether something is a free function, a member function, a type, an alias, an enum, etc.

Why not use CandyDoc? Originally from here: http://www.dsource.org/projects/helix/wiki/CandyDoc
It has a package tab, a list of all packages and modules, basically what's now in the left side menu. The other tabs is the outline tab which lists all declarations in the currently selected module. BTW Tango uses a modified version of CandyDoc.

> 2. The documentation only uses indentation to indicate the relationship between the different elements.  Look at the documentation for DateTime.fromISOString(), for instance.  You have to do a fair bit of scrolling to figure out whether it is a free function or a member function, and of which type it is a member.
> 
> 3. It is not possible to impose any structure on the documentation, beyond the one given by the code.  In the recent discussion about the std.algorithm docs, Adam Ruppe suggested a Tag: section, so you could tag an std.algorithm function with 'searching', 'set operation', 'sorting', etc.  That would probably do wonders for std.datetime as well.
> 
> Fixing these issues would go a LONG way in improving the documentation. (And it seems Andrei and Adam have both been working on this lately.)
> 
> -Lars
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg