General information
Category:
Object Oriented Programming
John,
I think you hit the nail on the head with a couple of the issues. Specifically, I do prefer independence from external components. I make several exceptions, but I do prefer to create my own ADO-like data objects.
Still, there's a big difference between passing a table/cursor to a function, and having one returned. I don't know if I agree that tables and cursors would have to be objects to be returned. Why not just return a work area, and have the cursor open in that work area? Also, I'm not sure I totally agree that tables and cursors are not objects. Certainly, in the literal interpretation of the word, they are not OOP objects. But I think a philosophical case can be made that they are objects, and in many ways, can be treated as such.
On a related note, I have done some reading of late on Object Oriented Databases. Though tables and cursors are not strictly objects, they certainly could be. I think that might be an incredible enhancement to the language. It seems that the fundamental elements of objects - encapsulation, inheritance and polymorphism - would be very powerful features to have in tables.
Finally, though ADO is perhaps considered an open standard, is it really open? Do I have access to the source code? Can an ADO object be implemented with Oracle running on Unix? It's not a standard like HTTP, IP, XML, etc. It is a proprietary technology available to anyone using an MS operating system. Personally, that's most of what I use, so I don't care, but I'm not entirely comfortable putting all my eggs in the MS basket.
David
>David..
>
>>>and I'm prefer a native object oriented solution to a proprietary technology.
>
>What is proprietary about ADO? ADO/OLE-DB is COM after all. It works in a lot of scenarios. It is an open standard.
>
>To do what you are asking, you need an object. Tables/Cursor are not objects. Therefore, you would need some sort of representation of a table/cursor.
>
>Ergo - ADO!! or XML!!
>
>I suppose if you don't like ADO, you could roll your own solution by creating a custom VFP class. But why bother? MDAC is a fairly standard thing to have anymore. And, if the machine does not have MDAC, it is a snap to install.
>
>FWIW, in all of my ADO talks, for the past 3 years, I always started my talk with "Would'nt be cool if you could pass a table as a parameter to a function or method?" That is what ADO provides.
>
>I think your beef about proprietary technology is a little off-base. If you don't want to rely on external components, that is one thing. I can't fault you for that. Multiple components increases the complexity of installation and management. An all-in-one solution fixes that problem, but creates problems as well. For example, an all-in-one solution is limited, a fixed space. With components, you can extend your boundaries. COM allows this. Yes, COM is a MS technology. However, I would not call it proprietary. It is an open standard after all.
>
>With that said, you critique is well taken. You are in the right church, but the wrong pew.
>
>< JVP >
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only