By the way, your Spam protection doesn’t seem to like Safari.

What I am wondering is if you could do something better, and potentially faster, with objects – i.e rather than passing in the name of the called package, pass in an abstract Logger object – other implementations would then be implemented as subclasses to the Logger (which could be simple wrappers to code in standard packages).

hrm_salary_rules.set_logger(pLogger => LoggerFactory(‘log4pl’) );

Then the interface could be enforced by the class / object – any new implementations would need an adapter object writing.

Alternatively, rather than having a Logger class, you could have a more general Object class, and set_logger could inspect the object methods – there’s always a higher cost to runtime introspection, but there are obviously places where it has it’s benefits – although I can’t quite see them here (mainly as objects don’t play well with dynamic pl/sql in 9).

You could then combine this with other patterns, to create some kind of bean generator.

i.e. package initialise calls dependency_injector.inject_dependencies
dependency_injector reads configuration for the called package for things like observers, logger, emailer, and other services, to be injected into the package, via standard setters
dependency_injector uses dynamic pl/sql to set the relevant values from configuration where the setters exist

(I will admit that I’m struggling to think of an occasion when I’d need that much loose coupling, but I guess the point is less around giving ME the flexibility to change my logger, than giving someone else the chance to use their logger with my code)

Cheers, APC