>>I consider a wrapper to be any interface that hides complexity, whether it's object-oriented or just a plain old procedural prg.
>
>I would disagree. A wrapper is something thats wrapps itself around existing code, not just moving existing code, but actually moving existing code and giving it a new interface (for the developers view) to deal with issues like bugs and confusing, which is easier for the next developer to use (maybe yourself).
>
>I would think that simply moving some redunant code into a procedure and calling it many times is not a "wrapper".

Mike,

Seems to me that we're all kind of saying the same thig; perhaps with different words.

When I think of taking aome older piece of legacy code and 'wrapping' it with a new way of doing things I'm thinking of three things:

1. The old code - What are its requirements / parameters & what does it return, value-wise?

2. The 'middle tier' (if you will) that takes the new parameters and translates them into the needs of the old code and deals with what's left over. Also it re-translates any returned values from the old code into the new needs.

3. The 'outer' layer which could be a PRG, SCX, COM object, don't really care. IOW, this 'new' interface allows the continued use of the old code.

Of course, given the amount of work this could be I'd just as soon rewrite the old sytuff. *g* That is, unless it's way too complicated.

For example, you might take an old procedure that returned error codes of a non-traditional sort and translate them into a standardized set of error interfaces.

Best,

DD