>This is a very interesting approach. The only trouble I
>see is that storing your object data in a property array
>steals away the ability to reference the data in any
>meaningful way.
>
>Would you rather access object data like this:
>
>? Customer.Name
>? Customer.PhoneNumber
>? Customer.Address
>
>Or this?
>
>? Customer.Data[1]
>? Customer.Data[2]
>? Customer.Data[3]
>
>I would pick the first approach. However, you could have
>descriptive properties and include a method that stuffed
>the property array before blowing it into a memo field, but
>I imagine there would be severe performance drops.

Well, the array tip is quite a good idea, since it saves you a lot of coding. But Chris's point is very important too. I prefer to have descriptive names (after all, that's what OOP is all about!). So I did the only thing I think I can do: I didn't include my properties in an array, but created a "save" method that returns a string with each of the properties(which I can then save to a MEMO), then I also created a "load" method that reads a string and converts it back to the ol' "properties format".

This way I think I get the best of both: Properties with meaningful names, and the ability to save/load my objects to a table! The only problem is that I need to test my save/load algorithms, since they would need to be SUPER fast...

But this is the only way to go for me, since I have a class that has an array of OBJECTS as one of its properties, so I need to store each of the array's elements properties... Tough!

I think that VFP should migrate to Object-Oriented Databases since we are encouraged to use classes in Visual FoxPro, why can't we manipulate them as fields? Beats me... ;)

Thank you for your tips!!
Roberto Cota