Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
environment idiom
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-12-10 (10:52)
From: Andrej Bauer <Andrej.Bauer@a...>
Subject: Re: [Caml-list] environment idiom
> I am interested in the idiom of passing a number of parameters by some
> kind of "environment" variable.  Think of a web server with hundredes of
> functions for processing markup and other things, only 3 of which need
> to detect the browser.  It's bad maintainability to explicitly pass
> browserid through hundreds of functions which don't use it.

I have had some experience with precisely this sort of task. I expected,
as you do, that explicit passing of arguments would be bad. So I came up
with a solution that is a bit like your lists of polymorphic variants.
It worked out ok, but was a bit hairy.

However, I was wrong. Later I also implemented another web application
in which I explicitly passed around arguments (I used labels because so
many arguments were strings that it was too easy to mix them up).
Contrary to my expectations, the code was neater and cleaner, not to
mention that it was type-checked at compile time.

All in all, I want to convey my experience: in sane programming
languages it is ok to pass around arguments explicitly, even if it looks
like there will be a lot of uncessary passing. In fact, this is an
illusion. The language  forces you to organize your code neatly and you
will end up passing just the right things to just the right functions.

A good compromise turned out to be the following. I used the ocamlnet
library which has the "cgi" object that encapsulates everything that
needs to be known about the HTTP/CGI request. Passing this object around
when needed, rather than passing little pieces of it (such as browser
id), turned out to be the right way. To be honest, you'll never pass
around "Bananas" and "Apples" but actual info that came from the
HTTP/CGI request. All the info is already known at the beginning, it is
neatly wrapped up in the cgi object (if you use ocamlnet), and you will
never wish to add anything to it. So you can forget about "extending
objects/records incrementally" because you don't need that (try to come
up with a realistic example). If you do wish to pass around additional
arguments, then you just pass them explicitly, and leave alone the
object that encodes the request you're handling.

Perhaps one piece of information that you want to pass around, and is
not stored in the object describing the cgi request, is database info.
You want to know what database you're connected to. Since my application
is not multi-threaded, I cheated and used a global variable for that.
You may want to pass around database info.

In my experience, you should always pass precisely the arguments a given
function needs, and no others. If you think "I will always pass the cgi
and database arguments, because I do not know who will need them, and my
code will achieve grandiose uniformity" you are likely to make a
mistake. You _should_ know who needs the cgi and database info in the
first place, and so should the compiler. So be as strict as possible--it
pays off in smaller and more managable code.

I tried it. It works.

Best regards,