Revamping the module hierarchy (was: ANNOUNCE: OpenGLRaw 1.0.0.0)

[Johan Tibell]

On Tue, Jun 16, 2009 at 4:45 PM, Ian Lynagh <igloo at earth.li> wrote:

> On Fri, Jun 12, 2009 at 10:46:07PM +0200, Johan Tibell wrote:
> >
> > Perhaps it's time to overhaul the hierarchy. Some top level module
> > namespaces like Network have become very crowded. Network is a very
> generic
> > name that it conveys very little information today when most software has
> a
> > network component. I suggest that parts of it be broken out into new top
> > level modules. As a first step I suggest we create a new Http (and not
> HTTP
> > with all caps please) module where we can have:
> >
> > Http.Client
> > Http.Server
> > Http.UrlEncoding
> > Http.Cookies
> > etc.
>
> I don't follow the logic. If Network is crowded, doesn't that mean we
> should be aiming to subdivide it, e.g. moving
>    Network.Http.*
> to
>    Network.Protocol.Http.*
> (FSVO "Protocol"; could be "Tcp", or something else entirely)?
>

Or Network.Protocol.Tcp.Server.Http? Or perhaps
Protocol.Network.Tcp.Http.Server? ;)

The argument I was trying to make is for some sub-module hierarchies (e.g.
HTTP) the word "network" communicates very little information and is thus
superfluous. Also the deeper we make the hierarchy the more difficult it is
to navigate it. Where would you expect to find a HTTP server module?

Network.Protocol
Network.Web
Network.Asynchronous

Here are three possible "answers":

Network.Protocol.Http.Server  -- How is a server a protocol?
Network.Web.Server  -- HTTP is a protocol that doesn't necessarily imply
"web".
Network.Asynchronous  -- This is an implementation detail.

Or even worse, an HTTP server might not live in any one module making it
difficult to find all the pieces you need for your current *task*.

Data.Http.Server.State
Control.Server  -- runServer
Network.Protocol.Http  -- sendResponse

I'm not convinced programmers think in these hierarchical terms at all when
programming. More likely the thinking is task based than anything (although
I need to find some evidence to support this view).

Also consider how many tokens you need to read when scanning e.g. an import
list to find the relevant parts:

Network.X.Y.Server
Network.X.Z.Uri
etc

Furthermore, if to module imports always co-occur I think the module
probably would have made more sense as one module unless 1) that would
result in one huge modules or 2) that is not possible because of name
clashes.

If we move everything up to the root then the root will be even more
> crowded than Network is.
>

Yes, a bit.

P.S. The module reorganization effort surrounding Python 3.0 might be of
interest for people in this thread.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090619/e17bf213/attachment.html