>>>>Methods of objects are better than UDFs as they allow the encapsulation of data with the behavior.
>>
>>When applicable. There is a price to pay in terms of modeling that is only paid back if reuse is guaranteed. Which in the real world (and I'm talking about the domain here) is not frequent.
>>
>
>I dunno, Marc. Seems to me not much more effort to create business/application objects and use custom methods instead of UDFs even if you never intend to reuse the code.

I think this is not a "two legs bad, four legs good" situation. UDFs have their place, and range of jobs to do; it simply takes some recognition of what should remain as an UDF, and what should be a method.

In FPD, I've had couple of date functions - FDoY() returns January 1st in the year of a given date, NDoY() returns the ordinal number of a date within its year, and ChkDat(date, startdate, enddate) returns a messagebox if Between(date, startdate, enddate)=.f.; now the first two will remain UDFs, while the third became a method in a DateTextBox class. I simply may need those two in any calculation, entirely GUIless, and the third has a GUI and is pretty pointless without a textbox to apply to.

Simply, the class of problems delegated to UDFs is reduced, but still not .null.