| If it is possible to keep the data-handling functions in .net, other commands like & and eval() might be handled (with a performance hit) outside the .net-runtime as com-based extension. I think JIT-technology should be able to work on VFP's p-code as well. Well, if Cobol can become a dotNET language without losing its data handling commands... how about VFP? Middle tier.
But wish to have an ability to run over the framework rather than through COM Interop,
though VFP's some powers like macro can't be used at managed environment.
I do not have opinion Wait until the .NET hype dies down and the product is stable, then if it hasn't died altogether (VFP or .NET) review integration. Create a CLR compliant compiler. You are getting a big head if you think VFP should have Better Universal Thread connectivity. It needs to share the CLR environment so it can be used for modules interchangeably with VB.Net and C# I think it would be better if it was part of the framework. Allow at least VFP COM components to be created right in VS.NET like it was in the VS.NET Beta compile in the clr New Languange X# replace xbase, replace cursors with XML Get out the bugs! expand the Common Language to include VFP specific commands and functions 1 - Providing Optional ways to use FoxPro. eg: With/Without DML support.
2 - Providing the ability to compile .DLL and EXE Files that may/may not require the VFPx.DLL to Run.
3 - Thruought a faster data-centric aproach to XML data handling. If COBOL and VB can be made to fit the .NET language requirements. I am sure that a VFP version would be possible, maybe even secretly underway. I'm not really aware of what advantage tieing into the .NET structure would provide Foxpro. Though I could see why integration with .NET would help Foxpro become more accepted in the developer community. The VFP Team and other MS experts are much better qualified to answer this than I. All they need is the will to make it happen! The ONLY way it can: COM and XML support (including support for DataSet) Yes In any fashion that does not affect VFP's legendary speed. Ability to write managed code from within VFP. native VFPDatadapter for ADO.NET, assembly interop... Unsure at this time. Why should it? Well, obviously by implementing it. Otherwise it realy doesn't matter. I'm not qualified to render an opinion on this. Visual FoxPro needs larger database capability, better SQL 92 compliance, and better support over TCP/IP including an engine that listens over a designated port and responds to SQL 92 sqlexec() in much the same manner as MSSQL, Postgres, MySQL, DB2 and Oracle. This would allow it to be better used as a backend in two and three tier apps in a more traditional way. It would also make Visual FoxPro a player in the .NET platform. Also, Visual FoxPro could then function as a real backend to not only Native VFP Front-End Apps, but with ASP.NET, Perl, PHP, etc. Visual FoxPro and Net should become interoperable and run under all platforms including UNIX, Linux, and Windows.
Not so sure.
Should try and make it easier for the Developer Learning curve Who needs .NET? <% language="Visual FoxPro" runat="server"
*
* NATIVE CODE IN VFP INTO ASPX PAGES
* USING CLASSES OF FRAMEWORK .NET SAME C/SHARP
*
%>
or
VFP8 + Web Connecion = VFP9
Keep the software independant.
But build an adapter for .Net.
So the programmer will have both possibilities. No Opinion I don't have technical opinion since I have not use .NET until now. But I think, VFP would be better integrated with .NET if vfp's name has something to do with .NET (like VFP for .NET or VFP.NET). With that kind of name, the developer will instinctively search for those integration ability. Leave it alone and let it do what it does best,'RAD'. Where is it stated that integration is always a good thing? Seamless use of the .Net framework, though i don't believe this will be possible. Or, make the data centric commands of VFP available in .Net. Probably include VFP in the .NET IDE... to be interoperable with C#, VB.NET and VC++.NET Doesnt need to be. As long as the COM+ Interop works as advertised, that is fine. It would be excellent if it could be another language in the .NET framework. Not sure not sure if this integrates, but native regExp would be my #1 ER for VFP. Adding some of the good features of .net and by changing the name to VFP.Net.
I don't know .NET, so I can't really say. I do know that .NET is strongly promoted by MS, so something needs to be done, otherwise the outlook is dim for future versions. If Foxpro could access namespaces it would be a great benefit to our business Simply by integrating it with .NET!?!? It shouldn't be. Use the right tools for the job: C# for .Net, VFP for data aware thick clients. VFP 8 gives adequate web services tools to VFP - that is as good integration as is needed. I'd like to see VFP part of the .NET framework simply for the broader marketing aspect but I don't see how it is technically possible without losing VFP's strengths. Functions only. Working with Dates especially! I don't mind evolving away from the .DBF format. I think, by the integration with .net, Visual Foxpro will lost its respects. If MS is really developing X# as rumored, the integration may already be in the works. The biggest change would have to be in the .NET IDE, which is much, much less productive than the VFP IDE. That would be excellent - the .NET platform is the development platform for the next 10 years, IMO, but I really doubt this will happen. Really knowing about the problem, I still mean that VFP must fully be integrated as a .NET Language. don't have .Net expertise to offer any suggestions No Opinion VFP should be integrated as fully as VB and C#! I do not see a feasible way.
If .NET will be a success, VFP must become a .NET-language to survive.
This will entail
(1) support of the CRL
(2) subclassing from C#-classes
(3) being subclassed from C#
(4) support of recordsets.
But then this wouldn't be VFP, would it? You assume it should be? You assume I share that opinion. I don't. n/a No opinion. No strong thoughts Bring in the .NET framework. Make it a .Net compatible language! Make it just another CLR language It has to be native language like VB.NET (and for ASPX too) I do not have an opnion. It would be nice to at least have the option of running managed code. I know that "it would just be VB", but so what? Fox is better that VB anyway. :) Provide a webservices like messaging mechanism between .NET and VFP that does not require COM Program in VS.NET with VFP for COM+ Server Only Being able to read DataSets returned from .NET components and Web Services should be a good way to go. Compilin the source in IL to run on CLR plus visual tools to develop webforms. Another important thing is develop a framework to better support of object spaces through UML or XMI support, samples of that are products as Bold of BoldSoft, actually part of Borland Delphi 7 pro, for me this is the future of development, model your objects an execute it. I do not use .Net .NET?.. Wait and See...
I think that in the future C# maybe a languaje to learn, I do not think the same of VB .NET.. Should become part of the .NET family. Fox has lot of things to give and take from .NET.
If Eiffel can run as .NET language than there is no reason that Fox can not. Share the clr N/O Integration with .net UI possibly. I don't use NET at all (I simply don't have time to learn it and I don't use at work), but I know it will become one of the main languages in a short while. So I guess, the more VFP is integrated with NET the better it'll be Powerfull typing two flavors... .Net and DeskTop I hope he will not be integrated in NET. It allready a big concurent of Net. I think there will be created some SQL Server related objects. Porting the code to C++.NET or C#, and making it run over the CLR, then making some mechanism to call the framework functionality from VFP. Integrate Visual Foxpro IDE with the Visual Studio .NET IDE. Also support for running .NET compiled objects. Make it a CLR language - or it will die - period. All the talk about how that doesn't fit in with what 'VFP is' is bull.
Having to go through COM puts VFP years beyond - and makes it useless as a middle tier tool, compared to using .net classes. The notion that VFP is an ideal middle tier tool may have been valid a few years ago - before .net - but now it is an absurd idea.
Not interested in .NET na I do not know if this will be ever possible, but even staying with its own COM architecture and interfacing/integrating to the maximum extent possible with .NET is good enough :-) Have msft create a FOX.NET language alternative to VB.NET, C#.NET that can use the VS.NET build/edit tools and compile to use CLR. This would be a subset of the RICH VFP language, but would be optimized for data and speed - VFPs traditional strengths. So, just as C# is a number of steps away from C++, FOX.net would be a number of steps away from VFP. I am sorry that I am not more in touch with the community. VFP however is just not adequate to the job we are currently pursuing - our new tools are thin client and an Oracle back end - with xml middle tier framework built in .NET and related scripting languages. I could use some time for consideration - but have to let the world evolve without my limited hopes for the fox - a clever idea but not the only possibility. If microsoft backed it... The support from Bill Gates and crew over the years is not been there. Microsoft promotes VB... SQL.. WHY NOT VFP No opinion. Not interested in .NET. More direct COM integration. Don't, if it looses any of its functionality Native .NET implementation, even if it breaks existing apps (due to non-deterministic finalization, etc). At least the local engine would be accessible without an Interop hit, and much existing code could be ported / adapted. I have not studied .NET enough to answer that Don't see this as a priority as we may have to give up too much to integrate it in .NET The DBC could react just like SQL Server. Stored Procedures could be interrogated just like MSSQL SP's. Just better OLEDB functionality all-around so it can be easily used like the Jet and MSSQL providers. I really can't answer this question because I haven't used .NET (yet) - I'm too busy developing a stand alone VFP app right now. I don't know if it can be. If we get Net-Centric we might as well just write in .Net. I have no idea, sorry. using a server-side providers of compilers I don't know. Probably the best would be to make it a fully .NET language. I think that if visual foxpro want to improve it's ability, it must import strong type and structure. No opinion as not a .Net user yet COMPILE TO IL I don't know if I see a real future for VFP beyond the next couple of years, so I'm thinking the only chance for the long term viability of VFP is to become a fully integrated part of .NET. As I described to Ken Levy, it was originally planned that Fox would be part of VS.NET, but in attempting to re-write Fox against the .NET CLR, the developers came to the realization that the CLR does not contain the technology necessary to duplicate the Fox engine. Therefore, I suggest exactly the opposite approach: duplicate some or all of the CLR in the Fox engine. For example, can the Fox team add a set of CLR-compliant data types, i.e., in addition to the current Fox DateTime type, could we declare a variable of type NETDateTime, which would be manipulated internally in CLR-compliant format and eliminate the overhead of converting types when crossing the COM boundary? Can we hook into WinForms / WebForms?
We should have a VFP.NET compiler. It's a pain in the neck to deal the complexity involved in data access in current .NET languages. VFP.NET could implement wrappers around ADO.NET to let programmers use typical VFP data commands and have the compiler transform them to .NET-like commands. It has been possible to port COBOL to .NET. Of course VFP can be ported as well. It's just fine now I don't yet have an opinion. More XML features,better COM Interop
In the same manner it was with Visual Studio. Allow VFP development throught the VS.NET interface when both products are installed. Include the VFP runtimes into the .NET framework so that VFP apps, COM dlls, etc. can be better incorporated with a .NET app. With improvements to VB.net, VFP for could be replaced completely. VFP's only stri=ong hold is in companies that cannot afford the SQL Server, price, hardware and maintenance. dont know yet |