Browse thread
environment idiom
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Andrej Bauer <Andrej.Bauer@a...> |
| Subject: | Re: [Caml-list] environment idiom |
It seems that John Skaller and I have different experiences, which is to be expected (unless compilers are like web applications, which I doubt). Clearly, as John and others pointed out, we can usually predict that certain sets of related arguments will be needed frequently, so it makes sense to make an exception to the "pass exactly what is needed" rule and bundle such sets together (as objects/records describing cgi request, host info, database connection, user-session etc). To repeat myself: this is what I did in my second attempt, and the results were better than the first attempt, when I stuck everything in a lookup table. John claims things get complicated in my proposed solution when code is unstable and requires lots of changes. He offers a C/C++ example of the const pointers. I am not convinced that ocaml and C/C++ are comparable in this respect. I habitually abuse the ocaml compiler to tell me precisely what needs to be changed in the following way: I change a type or value definition (say, change the arguments to a function) and keep running the compiler until it reports errors, fixing them as they come up. Had I used conglomerate lookup tables instead of arguments, or any other form of argument passing that the compiler cannot analyze, the compiler would be of little help. You would just postpone the problem to runtime. But don't get me wrong. I definitely agree with John that having 10 arguments to a functions sounds like too many, and something needs to be done in such cases. It's just that in my web application (and I suspect in most) I don't have 10 arguments all over the code, but more like 3 or 4, which is ok. Certainly different types of programs require different solutions. Best regards, Andrej