Advanced Oracle PL/SQL Programming with Packages

3.12. Obliterating the Literals

There are still two things that bother me about the repeated function: first, the function is not defined in a package and, second, a user of repeated has to know the correct literals to pass to it to get the right kind of conversion action. On general principles, I believe that everything built in PL/SQL should be placed inside a package. This construct is the cornerstone of programming in the PL/SQL language and offers many advantages, explored in detail throughout this book. My second concern about literals can be answered by creating a package—so I will show you how to convert the standalone repeated function into a package.

I do not believe that a user of my code should have to remember the specific characters to pass in a string literal. Is it UL or BS? Is it n for "no action" or l for "leave alone"? With the function as implemented throughout this chapter, there is no way for a developer to know at compile time if she called repeated properly.

Beyond this difficulty, applications the world over would be much better off if their creators avoided the use of hard-coded literals in their code. Every time the repeated function is called, some string literal is being hard-coded into a program. If the repeated function is ever modified to expand the scope of action and different literals are used, all those other programs could go haywire. A much better approach would provide named constants in place of the hard-coded strings so that (a) at compile ...