Hi Jim,
Now we're getting somewhere. *g*

I would be interested in seeing an example of a udf() you regretted not classing. It could really turn my thinking around.

If I understand you, you're saying that once you decide to wrap a native VFP function, you always wrap it in a class. 1st so that you maintain the same strategy pattern (oApp.oObject.Method(...)) and 2nd because it will be easier to add/change functionality down the road if you need it.

I respect that argument tremendously.

Now my argument (which I'm not convinced of anymore). This argument ONLY applies to simple examples, like wrappers for function calls. Anything that starts getting complex automatically goes into a class.

Using the MessageBox Handler as an example:

As Terry Thurber pointed out on this thread. All class methods are procedures. All the MessageBox Handler does is move my MB.PRG into methods in the class, and organize it differently. What we are basically talking about is HOW do we reach that Method/Prg.

If we want to call the MessageBox with a universal syntax (either oApp.OMB.Display(...) or MB(...)), then we both have to add parameters to the call in order to add/change functionality, and add CASE structure in the Method/Prg to handle the additional parameters.
The additional parameters can tell your oApp which subclass to use, or my Prg which subProcedure in the PRG to call. Your subclass may only change 1 property and my subProcedure would only change 1 variable.

I would bet that any example that you can come up with that would force me to duplicate code and/or create a different PRG, would also force you to duplicate code and/or create a different method.


The only argument I can see that I can't argue with:
If there's something that can be kept in memory so as to speed things up (like a custom msgbox screen), it has to go into a class. But even then, (say I want to create my own msgbox screen later), I can change the code in MB.PRG to call the Object.Method().

FUNCTION MB(...)
  RETURN oApp.oMB.Display(...)
  ... Old code that called MessageBox(...) moved to oApp.oMB.Display()
END FUNCTION

In fact, that's what I'm trying to decide. Seeing the MessageBox Handler class in the Component Gallery caused me to ask "Should I change my MB.PRG as above?". But I can't see any advantage to it.

In conclusion: I think it boils down to the strategy pattern, which I assume is just a matter of personal choice.




>>>1. Can easily subclass the class to vary the functionality without needing another function and syntax for its use
>>
>>This is 1 of the things I consider when deciding on a VCX or PRG. But in the case of something so simple as a MessageBox, #2 becomes a significant factor.
>>
>
>>>2. The object can be instantiated by the application object and held as a system level utility object so calling it is simply;
>>> oApp.oMsgBox.Display(...)
>>
>>How is this simpler than:
>>MB(...)
>
>Actually I prefer the use of a strategy pattern here where the call is oApp.MsgBox(...) and oApp decides what to do with the call.
>
>
>>>3. Since oApp holds the reference to the message box object oApp can change the class being used at its own discretion thus providing a single location for changing the appearance of the message box for the entire application.
>>
>>just changing the code in MB.PRG changes the appearance of the messagebox for the entire application.
>>
>
>Using a strategy pattern allows each call to decide what type of msghbox it wants. With Functions you would need a separata function for each type of msgbox and the calls would vary for each type. With oApp.MsgBox(...) one argument could cause oApp to use a completely different class for the msgBox object allowing a virtually unlimited number of variations.
>
>>>4. Since the oApp object holds the object reference there is only one place to deal with its release, which sort of negates the argument that there is some problem with cleaning up after the object.
>>
>>with MB.PRG there is NO cleanup involved at all
>>
>
>And so it could be using an object as well if at the end it destroyed itself.
>
>>>5. The interface to the message box could be designed into the oApp object (making the calling syntax something like oApp.DisplayMsg(...) )so one of the arguments could determine which type of message box to use (tell oApp which subclass to use) and the interface to the msg box featres would remain consistent across all types of msg boxes.
>>
>Just adding another lParameter to MB.PRG would allow the same capabilities.
>
>Not really, using the strategy pattern oApp copuld keep the msgbox in memory so subsequent calls were faster than the original call. Even the msgbox form itself could be kept in memory for future use (if you were using your own form for the msgbox) and since oApp will be destroyed when the app ends it can clean up any objects it created during the apps run on its own destruction.
>
>Besides, once introducing the idea of a stratgey pattern in the oApp object there are many other areas of the app that can make use of the same concept. Things like toolbars (shared between forms), other utility forms like selection criteria for locates or select commands, etc.. All opf this through one syntax of oApp.Utility(...) or whatever you descide the method of oApp will be for that functionality.
>
>I don't argue that a UDF doesn't have its palce, only that each time I have used a UDF it proved to be shortsighted on my part later on.