>>>>Why use classes? Procedural code gets the job done, right?
>>>
>>>Classes are for when there's data that must travel with the code. No point using a class for a bunch of functions that don't share data.
>>>
>>>Tamar
>>
>>I've you're talking about VFP classes, OK. If you mean classes in general and the foundations of OOP, that's a different story and I would disagree. They can work with the implementation of interfaces. If that last statement you made were true across all of OOP arenas, then certain frameworks would really never exist. :)
>
>Yep, classes to implement interfaces make sense, too. I've done that, but rarely enough that it didn't come to mind.
>
>
>Anyway, I'm happy to modify my original comment to say that in VFP, there's no point using a class for a bunch of functions that don't share data, unless you're implementing an interface. The point I'm trying to make is that putting a bunch of functions, even related functions, into a class simply to have them together isn't, in my view, a good approach.
>

Imagine buying 2 "packages" of source code: 1 for XML, 1 for JSON, from different vendors.
Luck might have it that both offer a "function" (not in vfp-function, but Javascript sense as "way to do someting, either stand-alone function or as part of an object(=method)" ) named ObjectToString(toObject, [tcReturn]) - which might be called from your SW and from the code package it was bought within.

No problem with Polymorphism if you have loXML.ObjectToString() and loJSON.ObjectToString, barely workable with the approach of having these functions in different function packages as you discussed with Christian above. Near recipe for disaster if split into single prgs. even if "living" in /XML and /JSON directories, as the bought packages calling the functionality expect "automatic" working.

As vfp has no Modules in the Python or newer Javascript sense or packages in Java land, putting "topic unrelated" functions together in a class just to avoid name clashes might be prudent.