Wiki Home

Should VFP Be In The CLR


Namespace: Wiki
See also Should VFP Become DotNet Should VFP Be In VSDotNet

Here's what I take issue with regarding the VFP "can never play in the .NET world" arguments:

1. VFP data engine != .NET data engine. OK, so what? Does this mean that there can be one and only one "DATA ENGINE" in .NET? If the .NET development languages and CLR are so powerful, why can't vendors build other DATA ENGINES in .NET for .NET? It took me 30 seconds to find the the following product which has a .NET data engine that claims DBF (I'm not sure about DBC) compatiblity: www.codebase.com/products/windows.

Here's two other "data engines" that are single, standalone .NET DLL's - both approximately 500K:

http://vistadb.com/vistadb_overview.asp
http://www.vistasoftware.com/apollo_net.asp

I understand that ADO.NET is the "official" data access strategy for .NET. So rather than thinking of the above products as "data engines", why not consider them "local persistent data structures optimized for set based queries"?

I see no reason why a VFP.NET type cursor engine, er, I mean "local persistent data structure optimized for set based queries", has to compete with ADO.NET. In other words, I don't see why both can't co-exist independently of one another as successfully demonstrated by at least 3 .NET vendors.

2. VFP's late bound interpreted mode means that a VFP compiler can never generate native .NET CLR code. OK, so what. Does this mean that all .NET languages HAVE to be COMPILED languages? Just because MS's first wave of .NET development tools has has abandoned scripting/interpreter based solutions doesn't mean that ALL .NET languages have to be implemented this way. Yes, I know that compiled solutions are much faster but the need for pure code efficiency is greatly diminished with the advent of low cost PCs (2G PC for less than $1K!).

See my notes on JScript.NET (below) that demonstrate how an interpreted language can successfully exist in the .NET environment.

3. Markus Egger does a good job (see Markus' comments further down in this topic) describing the issues of early vs. late binding and why this is an insurmountable(?) obstacle to building a .NET version of VFP. My counter argument is Microsoft's own JScript.NET implementation which supports both early binding (true compilation aka "fast mode") and late binding (interpreted mode with no variable declarations, adding properties on the fly, eval(), etc). Jscript.NET even allows one to mix and match binding modes (re: compiled/strict variable declaration vs. interpreted, late binding "VFP" style) in the same code base by bracketing code sections.

For the latest on Jscript.NET
http://msdn2.microsoft.com/library/72bd815a(en-us,vs.80).aspx

Some interesting quotes from the msdn JSCRIPT.NET site:

Re: Early vs. late binding - why not support both?

"JScript 8.0 is a modern scripting language with a wide variety of applications. It is a true object-oriented language, and yet it still keeps its "scripting" feel. JScript 8.0 maintains full backwards compatibility with previous versions of JScript, while incorporating great new features and providing access to the common language runtime and .NET Framework."

And ...

Re: Use of a non-typed language with other CLR languages

Any CLS-compliant language can use the classes, objects, and components that you create in JScript 8.0. And you, as a JScript developer, can access classes, components, and objects from other CLS-compliant programming languages without considering language-specific differences such as data types. Some of the CLS features that JScript 7.0 programs use are namespaces, attributes, by-reference parameters, and native arrays.

Re: "... nor would I want to convert all my code ..."

It is easy to make the transition from JScript to JScript 8.0 since you can include the new features into your code gradually. You can upgrade your scripts at your own pace, adding new functionality as you learn more about JScript 8.0.

I can understand why Microsoft doesn't want to create a .NET version of VFP. But I don't buy the technical arguments against why a .NET version of VFP can't be built.

If Microsoft is sincere in claiming that a .NET version of VFP really can't be built, then the root cause is failure of imagination vs. implementation details.

Malcolm Greene
Brooks-Durham
I think if you take a step back and ask...

Why would a VFP developer want a VFP.Net?

To me, the ONLY answer is, to be able to write .Net applications using a language that we are familar with.

As many have said, VFP.Net would be without the Data Engine, cause ADO.Net is the .Net data technology. It would be without VFP forms since .Net has windows forms... (although I bet the VFP team could teach the windows forms teams a few tricks to simplify data binding). It would be without Macros and eval(), you would have to use .Net reflection classes.

So, what does that leave us with in VFP.Net? As I see it, the looping constructs, comparison, math and string operators, and all the functions that don't have to do with all the 'pulled out' stuff.

IMNSHO we already have that in .Net. It is called VB.Net with the VFP .Net Toolkit. VB.Net is syntactially similar to VFP. The VFP .Net Toolkit gives you almost all of the VFP functions you might miss.

My internal 'logic' has always been along the line that MalcolmG expresses above.
The first counter-argument above - "...to be able to write .Net applications using a language that we are familar with." - sounds contrived to demean the intellect of the average VFP dveloper. What can possibly be 'wrong' with wanting to do the latest technology with "...a language that we are familar with."? Your implied suggestion that it is a bad thing is actually STUPID with a capital "S"!

Um, not at all. Actually, I was saying that I think VFP developers are SMART enought to learn the slight syntax differences between VFP and VB.Net or C#. I would rather do that, have done that, and still have VFP tool AS IS... than lose VFP as is, to have yet another slightly different syntax to build CLR apps with.

Your second assertion - "...VFP.Net would be without the Data Engine..." completely disregards MalcolmG's #1 "argument". Please, if you are going to dismiss this issue so smugly, at least provide reasonable counter-arguments to the arguments you (pretend to) refute.
Frankly your mind seems to be CLOSED on the issue and your statements above contribute nothing but FUD to the issue. -- Jim Nelson

Actually, I suppose that a VFP.Net could add managed classes specific to .DBF tables similar to the System.Data.SqlClient data provider classes. Then again, we can use the OLE provider with the VFP OLE-DB driver.

So, once again I ask. Are the small advantages a VFP developer would gain by being able to write CLR programs with VFP syntax and data provider out weigh the loss of the current VFP product with all that it provides. For me, the answer is no. I can work in .Net as is if it means I can keep VFP as is.

I keep hearing that making VFP CLR compatible would allow us to create .NET apps in a language with which we are familiar. I suggest that VFP made CLR compliant might be a very unfamiliar language. I strongly agree with the above statement. VFP's whole reason for being is it's self-contained data engine. -- Pamela Thalacker
This text was extracted from ShouldVFPInVSDotNet -- Mike Feltman

I think the issue is more of a technical one than otherwise. If VFP were intergrated into .NET and lost the qualities we have come to love in Fox, then it would be a major loss. But if it could be integrated without losing its personality, than I would be for that. But I don't think its possible. I personally would rather keep VFP as it's own product with it's own distinct features which make it different than to have it join .NET and become just another language to write code in. Greg Gum
IMHO the VS box question is a no-brainer - the real question is "Should VFP use the CLR? (= join .NET)" - If it is in .NET it will stay in the box, if it isn't in .NET it will get thrown out of the box next release or the one after. So - the .NET question - I don't see why VFP can't generate CLR 'intercode' and still retain its DE (its personality as Greg Gum puts it) - c.f. Harbour-Project/Flagship (both xBase/Clipper clones which both produce C as 'intercode' and both of which can natively access more than one data engine).
Separate out the DE (as a DLL or COM+ or w.h.y.) make it callable from CLR-based executables, and re-jig the rest of VFP to use the CLR. Microsoft might possibly not wish to offer the DE to every VS user, but Fox fans should encourage it (and isn't most of the cursor engine in ADO already?)
VFP isn't set in stone - it's a moveable feast so - Wish List:
Separate out the DE (see above) _and make it multi-threading_!
Combine Foxpro Forms and Windows Forms.
Support Web forms from Foxpro and provide Win2Web / Web2Win form conversion functions.
Go CLR (or watch out for Harbour - or similar - porting to C# and becoming a Fox killer).
Andy D 8-)#
Here are some technical thoughts regarding VFP and the CLR (by MarkusEgger):

VFP is intrinsicly late bound. That is a significant difference between the CLR and the VFP runtime. Consider the following code for instance:

USE Customers
WAIT WINDOW LastName

Fox can execute this code, because it is late bound. When the code runs, VFP opens that table before the wait window executes. When the second line executes, Fox can detirmine that "LastName" is a field in the database/table and uses it.
In an early bound (fully compiled manguage), the compiler has no way of knowing that "LastName" is a field (and not a variable that hasn't been defined and is therefore a bug). Therefore, the compiler could either ignore the possible problem, leaving the resultinging code with a potential crash scenario, or it could issue an error and stop compiling. Either one of those solutions would be bad.

You may now argue that the compiler could check the customers table. But then again, the customer table could be modified after compilation, so that wouldn't be save either.
*----ArtoT 06/22/2005
So what would be the difference in early or late bound if customer table IS modified after the compilation and there aren't any LastName field then. Uh.. both shows an error, yes?. Could we just assume that developper has to do also something to check situations like this and make app run?
*----
Also, consider the following code:

cTableName = "Customers"
USE (cTableName)
WAIT WINDOW LastName

Now we are facing a variable table name, and the whole scenario is hopeless in an early bound and fully compiled environment.

So to make this work in an early bound environment, we would have to do something like this:

Use Customers
WAIT WIND Customers->LastName

Not something I would be looking forward to (nor would I want to convert all my code...).

Here's another example that would be non-trivial to translate into the CLR

oX = CreateObject("SomeObject")
oX.Execute()

DEFINE CLASS SomeObject AS Custom
   FUNCTION Execute()
      * Do something here...
   ENDFUNC
ENDDEFINE

In this case, the object gets instantiated in the first line. In line two, VFP figures out what kind of object was instantiated so it knows what code to run. This is typical late bound behavior. In .NET, this is different. In C# for instance, an object would be instantiated like so:

SomeObject oX = new SomeObject();
ox.Execute();

In line one, we specify the type of object we would like to create (SomeObject) and then assign a new instance to "oX". For this reason, the compiler knows at compile time what code to run when the execute method is called (there is no other object that could be referenced through oX... unless it is a subclass of SomeObject and that would only work if the method was virtual and now I'm getting into stuff I don't really want to cover...:).

Note that in C#, no part of the first line could be replaced with a variable class name, unlike in the VFP example, where we could easily say:

IF Something
   cClass = "SomeObject"
ELSE
   cClass = "SomeOtherObject"
ENDIF
oX = CreateObject(cClass)

To make VFP work in an early bound way, we would have to build something like this:

LOCAL oX AS SomeObject
oX = CreateObject("SomeObject")
...

Or perhaps, we could even introduce a new way of creating objects:

LOCAL oX AS SomeObject
oX = new SomeObject
...

This would be the direct equivalent of the C# example above, with the exception that the command is split into two lines.

Either way, this would make the whole VFP language much less flexible and would remove many of the features we really like.

Anyway: There are a number of very similar issues that would change the VFP language quite a bit. I don't think that's something I want... -- MarkusEgger
Thanks, Marcus. That was extremely instructive, and now that I understand, I'm in complete agreement with you. - mda

The way is see it is to provide some sort of dual mode. That is, the old coding method would not be able to be compiled to CLR and the new coding method that support CLR. I did remember when OO was introduced into VFP. There were a huge uproar on the change. My message here is that, is change is needed or else we are going to lose the momentum. Just take a look at Dbase and Clipper. Where are they now? They resisted change and it did change their faith forever. My 2 cents worth.
KAKueh

Well, the thing is, once you start writing code like this:

LOCAL oX AS SomeObject
oX = new SomeObject
...

You could as well write it like this:

SomeObject oX
oX = new SomeObject
...

And at that point, you add a semi-colon at the end, and have C#. In fact, I would recommend for all VFP people who are interested in the CLR to look into C#. Once you get used to { and } and ; you are almost there... -- MarkusEgger

I doubt anyone has looked at this recently, but here's my two cents :D

Ok, VFP is obviously late-bound. However, anything can be, essencially, late bound, even in C#. Consider something like this:

USE (myTable)


Late bound? yes! But...

oTableHandler.Open(myTable)


Same thing! And to referance a table field:

oTableHandler.ReadField(myTable,myFieldName)

or even
oExpressionHandler.GetFieldOrVariable(myTable+"."+myFieldName)

But the point is that there is no advantage. It's just another way of specifing the same thing. A precompiler could easily change
USE (myTable)
to
oTableHandler.Open(myTable)


However, the disadvantage comes in how indirect the whole process is. You won't see any speed increase, the CLR will have to be 3-5 MB bigger in order to support

I dare say that one could build a FoxPro->C# code translator, if one could access the functions in the VFP*.DLLs (and documentation on how they work!). However, there is still no advantage, with the possible exception of lower-level control, with something like a #STARTCSHARP and ENDCSHARP compiler directives.

But still, it's an additional layer of indirection.

IMHO, we need to back up here and examine our motives for wanting VFP in the CLR.
1) No VFP runtime distribution is required.
2) It would be easier for Microsoft to combine it with their other language products in the Visual Studio.
3) Developers could embed code from various language products.
4) It would really annoy VB6 diehards haha no but seriously I suspect a major if unspoken reason is so that we would get a nice warm feeling of being at the cutting edge and not part of what is increasingly perceived as legacy techonology. -- Alan Bourke

Please feel free to add significant reasons to the above list.
Adding VFP to the CLR will NOT necessarily give VFP easier web development capabilities. And, in my opinion, this is much more crucial to the survival of VFP. If we could use the form designer and class designer to create visual objects that are compatible with web deployment, this would go a long way toward making VFP a serious player in web development. More so than CLR compatibility. Ray Kirk


Category VFP Future, Category Needs Refactoring
( Topic last updated: 2005.06.23 05:17:05 AM )