[erlang-questions] a plea for cleaner modules

[Ulf Wiger (TN/EAB)]

Ingela Anderton Andin wrote:
> 
> [...]
> 
> > Now, going through the list is a bit discouraging.
> > The following dependencies would cause porting problems:
> 
> >   [application, dbg, error_logger]
> 
> Well it is not exactly dependent on dbg. Dbg will never be 
> called in a normal run of the ftp, http clients you have to 
> give special debug flags for the dbg code to be run and it is 
> mainly there for convince instead of cluttering the code with 
> special debug macros doing io:format when some flag is set to true. 
> 
> When it comes to application it has to do with the 
> bootstaping (see below) and is not strictly necessary. 
> 
> error_logger is used to handle unexpected 
> "should-not-happen-normally" errors.  

Yes, I had noticed that these dependencies could be 
removed quite easily. The problem is that if a module
contains several things that are not strictly needed
to serve its main purpose, this extra stuff clutters
the code, and makes the module less reusable.

The main "porting problem" then is that in order to reuse
the ftp code, I have to strip out the parts that would 
cause problems, which means that everytime you update
the module in OTP, I have to do it all over again.

The ftp module was just an example. I've come across 
this several times before, and have certainly been 
guilty of it myself too. 

I think the main problem is often that it's difficult to 
know in advance what the best division into modules is,
and much of the gunk appears as a result of discovering
things along the way. So the initial structure slowly 
breaks down over time. And once it works, one may be 
reluctant to start restructuring it just for the sake
of asethetics.

A good refactoring tool and QuickCheck would certainly
help the situation. (:

BR,
Ulf W