🚀 go-pugleaf

In article <27705@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes:

> - Is this a reusable software component?
Yes - a classic example of the kind of reusability that functional languages
make easy. 

> - What are its characteristics that make it one? 

Simple interface.   

Use of reference parameters (structure pointers) as "magic
cookies" where the meaning is not known by the caller to hide the meaning of
the data.   

Use of function pointers to allow "call back" so that the module can
interrogate the caller.

[I should mention that all these are what is now thought of as
Object-Orientation....]  

> - Anything else relevant to producing a good reusable component that is
> reused ...

Now lets get to the meat!!

Here are a couple of issues that the example did not come to grips with...

1) Error and Exception handling.

In Paul's example, exception handling was simple.   He returns an error code.
But what happens to that error code in the module that calls his code?   Is is
passed back - and where, finally, does the buck stop?

Most modules end up needing some kind of error handling mechanism - and this
can provide a real headache for reusable components:-

	A function supplied by the caller?   

	perror(), followed by exit() - [I'm a C programmer]?   

	Pass back a return code - and if so what?

Each option is appropriate in some applications and contexts, and not in
others.   Yet the reusable module writer must choose one, since they are
mutually exclusive.   Hence (s)he looses potential customers for the reuse
whichever option is chosen.


	
2) Configuration

This is another embarrassment in re-usable code.   Configuration parameters
come in several forms:-

Size parameters: 
If one application using a reusable module must run in a
small space, it will want to make all structures (buffers, strings etc.) as
small as reliably possible.  A second application, though, has speed as a
priority, and wants them as large as possible.

Text strings:
Some target users like messages like "DBLX fault at 0xfc0040":  others must be
treated more gently, or speak different languages.

Magic items:
Patterns on a screen, locations of files, etc.

I can think of several ways to implement such configuration decisions:-

	Compilation constants (#defines) mean that the code must actually be
	changed for reuse.

	Parameters passed through a functional interface make the interface
	complex, and may mean that the calling application must "know" rather
	too much about the module.

	Configuration files provide a source on confusion and errors.

Any option may be appropriate, but each cuts out potential for re-use.

----------------------------------------------------

I don't have any solutions, or even preferred options.

I'm sure others have - any comments?

- Charles
--
Charles Weir, Rich Inc, 1400 Kensington, Oak Brook, IL 60521
Email: cweir@richsun.uucp  uunet!richsun!cweir 
Phone: +1 708 574 7424 X2766