Re: Converting to upper case

> I see at least one risk, however.  You mention the ability to enhance your
> functions.  Say you've got a particular function used in hundreds of
> applications.  You make an enhancement to it.  Are you going to test those
> hundreds of applications that use it?  If not, why not?  How can you know
that
> what you considered an enhancement does not actually introduce an error
into
> one program that has a "special case"?

Dan,

That's where the concept of an interface comes in.  A shared function should
do one thing, and one thing only.  The behaviour of the function is
well-understood.  There are no side effects (at least none that should be
counted on by the client).

In the current example, the procedure converts a string to uppercase.
Period.  That is the interface, or contract, between the service program and
the client.  If it does anything else, it is overstepping the mark.  The
only reason the procedure should be changed is to correct invalid behaviour,
such as (say) not converting accented characters.  If a client program is
expecting accented characters _not_ to be uppercased, it is making an
invalid assumption about the functioning of the procedure.

Basically, it comes down to good design.

--
Paul

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---