>>It's a philosophy. I believe in encapsulation. Most of the utility functions we've created over the years are black boxes. We rarely have to go and update them any more, just periodically, so it's not so difficult to find them.
>
>If they're black boxes, why would you want them to be used in any way differently than built-in functions? The need to include SET PROC means they're harder to use than built-in.

They are used as built-in functions, even with the SET PROCEDURE TO line.

Our apps generally have a setup function that's called at startup. It validates the environment, creates go* objects, loads various tables and what not, makes sure the data is there, performs a daily reindex if it's set, and other such things.

Adding a SET PROCEDURE TO line there in one of those startup functions encapsulates the necessary startup tasks in that one start.prg program.

>>What is your position on using stored procedures? They are encapsulated in a single location.
>
>Stored procedures are OOP-like, in that they travel with the data that relies on them. My view is that they should only be used for things that must be enforced at the database level, no matter where the database is used.

Agreed. You still have that pesky OPEN DATABASE (SET PROCEDURE TO) command...

...Even if it's implied.