Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Andrej Bauer <Andrej.Bauer@andrej.com>
To: caml-list@inria.fr
Cc: "HENRIKSON, JEFFREY" <JEFHEN@SAFECO.com>
Subject: Re: [Caml-list] environment idiom
Date: Fri, 10 Dec 2004 11:52:07 +0100	[thread overview]
Message-ID: <41B97FD7.50309@andrej.com> (raw)
In-Reply-To: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.com>

HENRIKSON, JEFFREY wrote:
> 
> 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,

Andrej


  parent reply	other threads:[~2004-12-10 10:52 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-09  2:07 HENRIKSON, JEFFREY
2004-12-09  4:47 ` [Caml-list] " Jacques Garrigue
2004-12-09  6:02   ` Michael Walter
2004-12-09 11:28     ` Jacques Garrigue
2004-12-09 20:02     ` pad
2004-12-09 23:11       ` Jacques Garrigue
2004-12-10  2:30         ` skaller
2004-12-09  9:09 ` Richard Jones
2004-12-09 13:12   ` [Caml-list] " Ville-Pertti Keinonen
2004-12-10 11:59     ` Richard Jones
2004-12-10 10:52 ` Andrej Bauer [this message]
2004-12-10 12:13   ` [Caml-list] " Richard Jones
2004-12-10 23:35     ` Jacques Garrigue
2004-12-11  2:30   ` skaller
2004-12-11 14:31     ` Andrej Bauer
2004-12-11 18:13       ` Markus Mottl
2004-12-11 23:56         ` skaller
2004-12-12  2:36           ` William Lovas
2004-12-12  5:33             ` skaller
2004-12-12 19:09               ` Michael Walter
2004-12-13  0:48                 ` skaller
2004-12-13  2:03                   ` Michael Walter
2004-12-13  2:05                     ` Michael Walter
     [not found]                       ` <877e9a170412121844b633bb8@mail.gmail.com>
2004-12-13  2:45                         ` Michael Walter
2004-12-13  6:18                           ` skaller
2004-12-13  7:08                             ` skaller
2004-12-13  9:56                             ` Michael Walter
2004-12-13 12:59                               ` skaller
2004-12-13  8:56                           ` Thomas Fischbacher
2004-12-13  9:21                             ` Jacques Garrigue
2004-12-13 10:05                               ` Michael Walter
2004-12-13 10:29                                 ` Thomas Fischbacher
2004-12-13 21:16                                   ` Michael Walter
2004-12-13 10:20                               ` Thomas Fischbacher
2004-12-13 12:09                                 ` Jacques Garrigue
2004-12-13 12:48                                   ` Thomas Fischbacher
2004-12-13 14:09                                   ` skaller
2004-12-13 21:39                                     ` Michael Walter
2004-12-13 13:22                                 ` skaller
2004-12-13 16:54                                   ` Marcin 'Qrczak' Kowalczyk
2004-12-13 18:44                                   ` Thomas Fischbacher
2004-12-13 10:11                             ` Michael Walter
2004-12-13 11:46                             ` skaller
2004-12-13  5:41                     ` skaller
2004-12-13  9:29                       ` Michael Walter
2004-12-13 12:30                         ` skaller
2004-12-13 13:49                           ` Martin Berger
2004-12-12 23:03           ` Thomas Fischbacher
2004-12-13  1:26             ` skaller
2004-12-13  8:37               ` Thomas Fischbacher
2004-12-13 10:53                 ` skaller
2004-12-13 11:38                   ` Martin Berger
2004-12-13 13:33                     ` skaller
2004-12-13 12:01                   ` Thomas Fischbacher
2004-12-13 13:41                     ` skaller
2004-12-11 23:29       ` skaller
2004-12-12  0:21         ` Jacques Carette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41B97FD7.50309@andrej.com \
    --to=andrej.bauer@andrej.com \
    --cc=JEFHEN@SAFECO.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox