>>
>>It is interesting. It might be a good practice to optimize even for small tasks. It's an acquired methodology. It would be difficult to turn it on just for big projects if our practices did not have a foundation in the little tasks.
>
>The general problem I have with optimizing while writing code is that, in many cases, optimizing makes the code harder to read, debug, etc. If there is some practice that doesn't effect those two but makes things more optimal performance-wise, I'm all for it.
>
>Like in this case, I'm not going to suddenly give up using objects. I may be a bit more selective when I use them, though (ask myself, is this going to get called 5 billion times? Maybe I should make this a function instead).

I don't give up either. Here's a practice that I would not use an object for. Call it the swiss army knife approach. This is basically an object that holds a set of methods which would each be a UDF/function in a procedure library. oApp is often used for this. Problem is when you need that method for a system, like a utility, but not an entire oApp.

If the methods of an object support the purpose of that object, they belong with the object.

If the methods basically extend the programming language or are unrelated to each other and/or the object, they should be PRG based UDFs.

If various objects call those udfs, I believe we get the best reusability and performance.