English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    
Browse thread
Re: [Caml-list] Naming conventions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Pierre Weis <pierre.weis@i...>
Subject: Re: [Caml-list] Naming conventions
[...]
> But, the original question was about objects.  In Java there is a
> style that is fairly convenient, whereby mutators for objects return
> the object itself instead of void (unit).  This allows doing:
[...]

Oh, please, no!

We had once these style of primitives in Caml and found it really
error prone: you just confuse procedures and functions!

A procedure is called for its side effects, hence it does not return
any meaningful value, and hence it reflects this fact in its return
type that should be unit.

Thanks to this convention, there is a special warning to help the
programmer not to forget an argument to a procedure call inside a
sequence of side-effects: if f has type int -> int -> unit and you
compile the sequence

begin 
 f 1;
 print_newline ()
end

then you will have a warning for the incomplete call f 1 (telling you
that this expression should have type unit).

If your procedures wrongly return a value which is not unit, then you
will have warnings everywhere; hence, you will disable warnings;
hence, you will miss partially applied procedure calls.

When programming in the large, such silently ignored side-effects are
a nightmare to find out, particularly if the given procedure has a lot
of arguments (imagine forgetting just the last argument to mult_nat, that
is just providing eight out of nine of the required arguments! It is
easy to find if the compiler points it out for you, otherwise you can
read the program over and over again without noticing the missing
arg).

So no. This ``fairly convenient style'' is not your friend; it is in
fact as convenient as programming without a type-checker: seemingly
``cool'' at the beginning, but really harder in the long run.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners