The "class" approach is clearly beneficial in code with multiple RETURN statements; e.g. code that does not adhere to the "single exit point" construct mandated by "structured programming". While the example provided is very bad coding practice, sometimes we "inherit" code like this from other developers.

FWIW, I don't disagree with your argument for using the native functions most of the time. I simply wanted to interject a scenario in which the class approach has real benefit over the setup/cleanup code pairing.


*- Now I can be sure that after this method exits, the original work
* area will be restored, with only 1 line of code. I don't have to
* ensure that I have matching "cleanup" code on each exit point, and I
* don't have to restructure the method.
loOriginalWorkArea = CREATEOBJECT("cSelect")

IF somecondition
RETURN
ELSE
continue processing until...
IF someOtherCondition
RETURN
ENDIF
ENDIF

RETURN



>>>And then I need to remember the name of this class, how to call it, etc. What if somebody wants the class which sets/restores TALK ON instead of OFF? Create another class, or add two methods to SETTALK class (or one method and pass the parameters), remember methods names, etc...
>>
>>Nope. Create the class to save the current state in a custom property (e.g. cOldSet) in Init() and restore it in Destroy() or thereabouts.
>>
>>Then you instance the class, it saves current state, you change it in your method/program, to ON|OFF or whatever the case may be.
>>
>>Upon leaving the method, the state gets restored automagically.
>
>Still, we are talking here not about single SET TALK case, but rather the consistent approach. Then, for all similar commands you will need to create more classes like that (and remember or look up their names), or one universal SET class and pass the parameters to it.
>I like to play devil's advocate on Fridays... :)