AnsweredAssumed Answered

vrf Object Oriented Programming

Question asked by VRFuser on Apr 5, 2006
> Am I missing something?

No you're not. Jeez, two in a row that are bound to get me in trouble!

No it doesn't support some of the concepts. In fact, it doesn't support any.

VEE exhibits absolutely NONE of the characteristics of any OO language to date. With the possible exception of a weak form of encapsulation. I don't care what the marketing literature says - these people carry degrees in business, psychology and (god forbid) liberal arts, not computer science. VEE is most emphatically not object oriented. At all. Just because it's written in an object oriented language doesn't mean it exhibits any OOness itself. If one wants to argue that VEE introduces it's own type of OOP then that's fine by me, but by other scales it scores almost zero.

Now, having said that let me also say that there's nothing forbidding the use of OO principals in VEE programming - just like every other kind of programming. It's the technique that makes the difference, not the language (I realize you get this by your verbiage by the way). The language can hinder or help the effort, but it doesn't make or break the technique.

Take your example: polymorphism. Consider a primitive case: C++ overloading. VEE has the Any type, and the typeName function returns the base type of Any. Therefore you can perform different actions depending on type: C++ overloading. Assuming of course that these Anys are inputs to a function or "object".

Now, for *real* polymorphism. I've actually seen routines that generate code on the fly and then execute it depending on conditions. Specifically, the value of parameters passed to a function, but the technique can be expanded to a program generator type scenario that would duplicate the function of a vtable. It's not like you're going to get anything like the speed of execution you'd want, but you could build a polymorphic function generator/executor.

Here's another example: C. Nobody I know would claim that C is particularly object oriented. This is in fact a language that hinders the concept more than helps it. And yet people were doing object oriented programming in C long before Bjorn stubbed his toe (or however the story goes). Windows is quite encapsulated and even polymorphic and yet it was written in C and up until recently sported an almost exclusively C API. The DCE RPC is almost a poster child for OO. One can almost see COM sprouting directly from RPC.

Ever since VEE 5 you can ignore VEE completely and do all your VEE programming with objects if you want. And now you can use .NET too and ignore VEE along another line of thought.

None of these abstractions really mean anything anyway. Sometimes they can help, but more often they hinder or hide. Just ask anybody who's familiar with MFC. It's a love/hate thing that goes right to the core of it's "object orientation".

The hiding is much more helpful, though that has it's bad points too. You don't *need* to know that a VB Collection is really a single linked list. Just go ahead and start using tens or hundreds of thousands of entries and you quickly find that an array of structures is a whole lot better choice. Same thing with a VB String. Don't try to grow it repeatedly or you'll find your beard growing while your disk thrashes.

In short, and as always, if the situation warrants then by all means use OO in VEE. Equally, if the situation warrants then use Patterns in VEE. Sometimes it's prudent to ignore all such abstractions and simply do VEE programming in VEE. Like I said, carpentry is not something you find in a lumber yard!