Hi Rick,

>>The matter indeed is abstraction and if the number of code lines are measured in the lines you idealy will have to program to solve a particular problem, you might be right, but I bet that in reality when doing this the first couple of years you'll be finetuning your framework classes as well, meaning that in reality the number of codelines programmed still is significantly larger than in a language where the code efficient functionality (like the DML in VFP) is embedded into the product.

>And you'll do the same thing with any development environment. VFP has many very high level abstractions so maybe there are fewer of these, but still you build libraries of stuff and you spend time doing framework code.

You're absolutely right: You'll have to do this in every language. But the lower level a language is, the more efforts in building a functional equal library (Assuming that the same functionality CAN be build in the higher level language).

For many functionality in regards to handling data you don't have to build a classlib, since it is a part of the language. The concepts of the VFP DML don't have to be build into classlibs as they already represent a well defined abstraction of the functionality you need.

>I would never use VFP code straight out of the box in a production app either.

Please explain this argument. When I begin a new project, I'll at some point have to define application specific classes (as the same functionality/GUI occurs on multiple levels within that application). All this code is NOT part of a framework, but is gathered in a application specific classlib. Esspecially when talking data, I don't see any reason why I should force myself to use framework classes to do a simple SQL SELECT, LOCATE, SEEK, UPDATE, INSERT. I agree that in some cases design paterns like a bridge makes sense, but in the case of these functions which are so well defined and every self respected VFP developer knows what it does, using classlib functions for these functionality seems just counter productive and leading to less readability.

So my experience says that for every application I'll have to define application specific classes, not beeing part of a framework. Within those classes, I'll use many complex functions out of the box without using a bridge to a framework class for many functions, just because they already well abstracted. This will mean that when going to do .NET development I'll try to implements VFPs DML functions into a classlib. When this is done, I totally agree, the amount of coding for every new system is not going to be much different from VFP. However, note that building such classlib with the same functionality of VFPs DML is a trivial and tremendous complex and difficult task.

Of course a much simpler path is to define a data handling strategy into a data layer which is much more simple and straightforward to implement, but then you're losing the granularity and flexibility of the VFP functions. And its funny that just the argument of granularity is used often in favour if .NET. When it comes to handling data, it seems a .NET implementation is either too granular (Do everything yourself again and again and again, like iterating and munging through ADO.NET collections)or not granular enough (Define the interface of a data layer and using business objects to handle the data related tasks). Well I'm sure it just a matter of time when granular functions that have an equivalent into the relational world of data (Like the SQL or XBase DML standard) becomes available, but until that day comes, it is clearly a disadvantage of the .NET framework.

Walter,