I did "only-in" for a while in a large system, proactively, for some of
the reasons you mention. I later decided it was a tedious and
ugly-looking pain in the butt with no actual benefit shown after years
in practice.
I currently try to have reusable modules provide names that are
reasonably unlikely to conflict, and calling that good enough. This
includes trying to put the package name in each provided identifier
somehow, perhaps in an English phrasing way, to hopefully give
programmers a better idea of where the identifier is coming from, as
well as to reduce conflicts.
("http://www.neilvandyke.org/racket-roomba/"; is not the absolutely best
example, since some of the names are based on opcodes from the spec, but
it's a recent open source example.)
I occasionally see someone doing a reusable Racket module that provides
generic names (say "get" or "open"), as if it's designed to be used with
"prefix-in" or in small programs that don't use many modules. It can
give simpler-looking demos of example code (e.g., code says lots of
"move" and "turn" rather than lots of "move-robot2000" and
"turn-robot2000"), but I think it turns out to be tedious (now someone
has to do "prefix-in robot:" anyway, or the module doesn't play well
with other modules. It also doesn't play well with Racket documentation
search, which likes us to have unique names even though modules mean we
don't have to. It also is not great for debugging, when you have only
an error-message string like "get: could not get" and it's coming from
an indirectly-required module that you didn't even know was being used.
Neil V.
____________________
Racket Users list:
http://lists.racket-lang.org/users
