An hour and a half ago, Matthias Felleisen wrote: > > Eli, could you share w/ us why > > tool/optimization-coach .. with everything in it for this software > tool/future-visualizer .. with everything in it for this software > > is a bad idea? Perhaps I am old but I do see a lot of value in a > deep hierarchical organization. [...]
* One reason is from a simple code organization point of view. I referred to the unix filesystem convention as an example of this: - On Windows, every application is in its own directory (there used to be files in the Windows directory, but they strongly push away from that) - On Linux, the Foo application will usually have /usr/bin/foo, /usr/lib/libfoo, /usr/share/doc/foo, /usr/share/lib/foo, /usr/share/icons/foo.png, /usr/share/info/foo.info, /usr/share/man/man1/foo.1 etc etc etc. - And the new kid on the block inherits a lot of unix-isms, but goes even further than windows in having the executable itself be a Foo.app that contains everything it needs... Now, in our tree we have a little of both -- for example, there are collects/foo/tests directories in some cases, and collects/tests/foo in other cases, and scribblings are similarly organized in two ways too. I think that the single directory is ultimately easier to deal with, even when there is a package system that can keep track of files in different places. There are *many* advantages that you can get out of it. To name a few: - It's easy to switch things around so that collects/foo is actually in its own repository, managed separately from the whole tree (and I think that getting to that point is absolutely inevitable) - It's easy to package it up and ship it somewhere -- just zip it, and send it with instructions for where to unzip it. - Things like ownership become very easy: you know that if it's in xrepl/* then you complain to me, and it's easy for me to see when someone else commits to xrepl so I can look at it. * Having said that, note that it isn't completely disjoint from using the directory structure in a way that follow its use -- the only thing is that the main "package name" comes first, and then a subdirectory like "tool" or "tests". *But* -- there is also danger in abusing the directory tree too much as a replacement for keywords/tags. Say that there's some "foo/tool/inspector" and later "foo/tool/profiler", what happens when there's a type inspector -- which keyword "comes first" in the hierarchy? (Incidentally, the first point makes this question easy for *me*: it's whatever foo's author wants to do...) * Finally, there are a few minor exceptions. "typed" can have subdirectories that are owned by other people, "file"/"net"/"data" etc are designed to be hosts for very common "keyword-like" uses. > Perhaps Google will eventually accommodate all these people who > don't like hierarchical organizations with search tools that find > everything, including their misplaced car keys, reading glasses, and > wallets. But we don't have such a tool for finding things in our > collects/ tree and until we have such a search perhaps we should > exploit the file system that we do have. Actually we probably do... I've set up a google code mirror, and they most likely have tools to search it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________ Racket Developers list: http://lists.racket-lang.org/dev