>>>Hi Cetin
>>>
>>>I'm already against the overhead of set procedure... ;)
>>>
>>>>>Hi Albert
>>>>>
>>>>>I strongly believe such a functions should be their own .PRG. If naming it is hard, imagine the added difficulty of trying to remember both the name and in what library to find it! Not only that, but you never even need a set procedure to to use it. That seems to me to make it even easier to use!
>>>>>
>>>>>It certainly should be a name that is explicit for the return value. You call the function for it to return something. You can comment the header of the function with keywords so you can find it again later, whatever you call it.
>>>>
>>>>Mike,
>>>>What about putting it into a class library (possibly a prg one). It might prevent other potential problems. ie: say FuncName as a prg, as a function in current procedure file(s), as an array, as a stored procedure. Precedence would kick in here and user might be stumped to get different results sometimes hard to debug. With a class library you'd have chance to alias it.
>>>>Cetin
>>
>>Overhead? How much overhead would you expect - a human noticable one?
>>Cetin
>
>It's not just performance it's also trying to find it later.

Oh you're saying finding separate prg names are easier than finding from a single (or few) class lib names?

local loLib as "myMath" of "GeneralPurposeLib.prg"
loLib = NewObject("myMath","GeneralPurposeLib.prg")
loLib.

After dot intellisense helps me. Would it with multiple little prgs?
Cetin