Re: Function Opinion

["Buck" <buck.calabro@xxxxxxxxxxxx>]

>I have a client that insists on creating service
>programs with only one function per service
>program.  I have always been of the opinion
>that all "like" functions should be contained in
>a service program together.

I think your opinion is shared by more people than your client's opinion is.

>That being said, are there any benefits or possible
>issues with having only one function per service program?

Managing concurrent access this way seems extremist to me (if that is the
rationale.) I learnt many years ago that I can't trust the source member to
be the same as when I made my private copy of it, and religiously check the
source change date prior to copying my changes back in.  Or, have a
programmer MOVE the source member (not copy it) so that no one else can come
in behind her.

There may be a run time activation time performance benefit to having many
service programs vs. few, but that might be cancelled out by the run time
expense to locate and authority check them all (which happens even if the SP
doesn't get activated.)

With one function per service program, how does one create a uniform set of
utility functions?  Sharing status flags and so forth?  Pass them to each
function as a parameter?  How does one know if a function has been created
already?  With many service programs, it becomes increasingly difficult to
locate an existing function for re-use.  How does one handle figurative
constants like return values?  /COPY them into every function and
re-compile/bind/deploy each one when the list of return codes changes?
  --buck