>Craig put it into words that made sense to me.
>
>But as Marcia and Hilmar pointed out, OOP is not necessarily the most efficient way to accomplish things.

Yeah, I saw Craig's post - that's a very good, easy way to look at it.

And I will certainly agree that just using oop to be "vogue" is not a good enough reason for me. It took several years of gradually shifting to using the oop code-style before I really realized the full benefits of tight object communications, encapsulation, classing, inheritance, reusability...

But once you get hooked, oop is fully addictive, and you generally won't even think about *not* using oop-code after a spell unless you're desperate and oop offers no way to do things (the menus that Marcia noted are one common case. Because menus are not oop, hence oop-coding does not work well with them, and I too use whatever works). Meanwhile hoping someday menus will get oop...

But for the most part, even if the oop code may be a little more work at times (especially at first), it's generally going to be more reuseable, better-able to communicate with other objects, and much more reliable as a long-term standard (each version, vfp drops a few more of the oldy-moldy functions), and certainly oop is more flexible to work with.

One thing I would add is that I think there's a rather thick line, though sometimes grayish in color, between non-oop *data* functions and non-oop *object* functions. At least this is my take, from doing the whole transition from Foxbase thru vfp8.

The object-code (visual or not) has gone decidedly oop, and there's no going back on this. The non-oop object functions (like the W***()s) will gradually fade away into the non-oop graveyard. Above all else, that's why I recommend going oop as much as possible. Oop is not only the "here & now," but the future as well.

But for the *data* functions, the same is not true at all, IMO. Xbase is still Xbase, just a lot more nicely dressed up in DB containers, buffering, etc., but we're still going to be using many of the same/similar old basic Xbase functions for a good long while. The Fox data engine has always been the best, or among the best, and no one's going to make a big change in that anytime soon. Why would anyone monkey with the vfp data engine and related components and functions, it's already so very good. A little tweaking? Yes, of course. Massive overhaul? No way. Again, my opinion only.

If you do much .NET or web-related data-object coding & binding, you can apppreciate why data-ooping is not a whole lot of fun.