English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
warning on value shadowing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-02-23 (20:51)
From: Sam Steingold <sds@g...>
Subject: Re: warning on value shadowing
Jacques Garrigue wrote:
> From: Sam Steingold <sds@gnu.org>
>> Proposal:
>> When both foo.ml and bar.ml define zot and quux.ml opens both Foo and 
>> Bar, there should be a warning (when compiling quux) about Foo.zot being 
>> shadowed by Bar.zot (or vice versa, depending on the order of the open 
>> statements).
>> If you think this is an overkill, please at least consider issuing the 
>> warning when zot is used in quux.ml.
>> If you think that is also an overkill, please at least consider issuing 
>> the warning when foo=quux.
> The first one is clearly overkill: if nobody uses zot, then who cares?

you are not using it NOW, but you might in the future, at which point 
you will all of a sudden have to refactor your code to avoid the 
warning. I would rather see the shadowing warning the moment I add "open 
Foo" for the first time.

> The second one might be useful, but it creates some problems.
> For instance, it is common practice to open Format or Unix, and have
> them intentionally shadow definitions from Pervasives. Should we make
> an exception for that? But it is not so infrequent to do it  with
> other modules too (for instance open Printf, then Format). For this to
> be practical, the language would have to be enriched with finer grain
> control on imports.

you should be able to say something like
shadow Foo.bar with Baz.bar

> How bad is the problem in practice?


silent shadowing is one of those "low probability -- high consequences" 
situations. the fact that you personally have never had to spend hours 
chasing a stupid bug that should have been uncovered by the compiler 
does not mean that silent shadowing is good practice.

> As for the 3rd case, I'm not sure what you are pointing at.

bar.ml defines zot.
foo.ml contains this:
	open Bar
	let zot = 1
compiling foo.ml should warn me that foo shadows Bar.zot.