From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 3D87FBB91 for ; Sat, 11 Dec 2004 03:31:11 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iBB2VAD1006200 for ; Sat, 11 Dec 2004 03:31:10 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA00976 for ; Sat, 11 Dec 2004 03:31:10 +0100 (MET) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBB2V8Rx010793 for ; Sat, 11 Dec 2004 03:31:09 +0100 Received: from [192.168.1.200] (ppp203-65.lns1.syd3.internode.on.net [203.122.203.65]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iBB2Uc0r073974; Sat, 11 Dec 2004 13:00:55 +1030 (CST) Subject: Re: [Caml-list] environment idiom From: skaller Reply-To: skaller@users.sourceforge.net To: Andrej Bauer Cc: caml-list , "HENRIKSON, JEFFREY" In-Reply-To: <41B97FD7.50309@andrej.com> References: <9410EC84C0872141B27A2726613EF45D02A52E08@psmrdcex01.psm.pin.safeco.com> <41B97FD7.50309@andrej.com> Content-Type: text/plain Message-Id: <1102732237.2611.580.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 Dec 2004 13:30:38 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41BA5BEE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41BA5BEC.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 andrej:01 wrote:01 imho:01 abstraction:01 imho:01 minor:01 buffer:01 'const':01 'const':01 const:01 const:01 pointers:01 compiler:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Fri, 2004-12-10 at 21:52, Andrej Bauer wrote: > 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. IMHO the issue is not whether to pass arguments explicitly, there is clearly no alternative. The question is how to organise them. For example you can use several actual arguments, but at some point there are too many for sanity and you need to, for example, pass a smaller number of records. However this provides no abstraction. > 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. Hah -- at least you're admitting you cheated -- LOL! So how would you fix this? > In my experience, you should always pass precisely the arguments a given > function needs, and no others. IMHO you are almost right but not quite. The reason is that code gets changed. If you pass exactly the arguments needed, your calls would be very long winded and even a minor change in implementation details or code structure would propagate to every caller, direct or indirect, of that function. So that isn't even a marginally viable option in an unstable code base, and in a stable one information hiding serves no purpose. Instead of 'precisely', change the requirement to 'roughly'. What does that mean? It means you need to factor your argument sets so you pass precisely the argument classes needed by each function, even if the function doesn't need all the members of each set. Now if you make a detail change to the code, you have a *buffer* of 'a few extra arguments you might or might not need when you change the code' which will dampen the propagation shock wave caused by a small reorganisation. The 'classic' example of this affecting a massive number of programs and programmers is the const-propagation phenomena in C/C++ when you take a program not using 'const' typing, and try to adapt it to provide the extra type safety 'const' makes available. Doing this was made mandatory by the ISO C committee, since they decided that some library functions should be const exact -- in particular return const pointers where previously only non-const ones were returned. Modularity, then, provides some protection against this. 'Correct' structure is not something you can determine for an unstable code base. If you could, that would be an admission the requirements were stable. (In that case there is no point refactoring the code to make it prettier.. unless you are just researching or intend to publish it ..) I'll add my data point: in the Felix compiler I used to pass individual arguments around. However the lookup in particular consists of a large number of mutually recursive functions all with slightly different needs, which are the sum of both what they need, but also any function they call .. and worse, they're combined with 'let rec' which is basically not expressive enough to reflect the true call graph (but the alternatives such as open recursion have other problems like adding to the number of parameters ..) I did three things to try to fix this. (1) I grouped some of the data into a record (2) I forward defined a couple of functions at the expense of passing extra arguments. (3) I simplified the requirements in one case, and totally dropped a whole section of functionality The current situation is still FAR from satisfactory however. most of the function require about 10 arguments -- still too many. The *problem* is that i AM calling the functions with 'exactly the required number of arguments* and it makes changing the code very hard. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net