× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



>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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.