>Just an observation here (basically I agree with your view), but isn't this just a "roll-your-own" form of object oriented programming - you use the same function, but the effect is different based on the caller ? In normal OO programming, the detail of how the different function (method) is called is usually hidden, in this case it's done manually.

I wouldn't say so. In thinking about this, the words "abstract class" come to mind. An abstract class simply defines the interface an object presents to the outside world. As an example from my work, consider having to deal with the possibility of using two different spreadsheet programs as automation servers. OTOH, I could've used a reference to which server was being used within its various methods. I chose a different approach. Since the tasks, regardless of the server, were identical, I created an interface for them. For example, printing the current sheet, setting the current sheet, retrieving a range object, and even manipulating the visibility and window characteristics. I did this because the syntax for doing these things was different between the two applications. This led to smaller code modules, that, in the future can be more easily maintained. IOW, I don't have to worry about what applies to what within a them.