I'll pick up a few things based on the "object" return I proposed earlier.

If there are any object aware gurus listening, please
  • Shoot this idea in the head if it is simply not possible
  • Come up with a working object to demonstrate it if it is, heh [Wink]
BrianTX
quote:
I'm not sure how it would be possible to take both scenarios and mesh them together in one "standard" system of error coding. Some disadvantages for doing so are: (I know I'm repeating what has been said)

1. Making simple, straightforward UDF's harder to use.

2. Lengthening code unecessarily.
The point of meshing them using the object actually addresses both of these issues. If you use the return value as you currently do it will continue to work regardless of how it was assigned in the UDF. This means that there is no change in how you use the UDF. Use it the simple way or the advanced way, both will work transparently.
This of course also answers your second point. You can have the "extended" code both in your calling script and in the UDF, in just one of them, or in neither of them. There is no more code unless you specifically want to include it.

Shawn
quote:
Returning other things like extended error codes along with the data, i think, is not a good idea. In fact, it would make the UDF in-flexible in that it couldn't [easily] be plugged into collection-aware contructs
Yeah, this is what started me thinking about abstracting the return value using objects. The well constructed object would accept an array as the value assignment, so:
code:
$udfReturn=$avMyDataArray
would continue to work, and the dataset would be kept clean.