Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Summit, VFP, Disclosure, Musings
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00588784
Message ID:
00590405
Vues:
53
Jess,

A few questions.

> Majority of my colleagues here want VFP to be .Net language.

First question, what is a .NET language? Is it a language that can consume .NET services? If so then VFP is already one.

Is a .NET language a CLR langauge? Then why do you want VFP to be a CLKR language? What does being in the CLR buy you that you don;t already have?

> Regardless of technical reasons why it should NOT be, it doesn't matter and
> we don't care.

Interesting philosphy. We should just ignore all of the technical reasons for anything and just plod on.

> Why some of you keep on saying that we'll be losing majority of VFP
> features?

Because the CLR doesn't support them?

> JVP said "...despite impressions to the contrary, VB .Net and VB are very
> much the same. Yes, there are some differences, but in all material respects,
> they are the same."

I don't recall seeing JVP say this. I do recall him saying that in his opinion there was very little different between VB.NET and what a CLR version of VFP would most likely be.

> If VFP will not play with .Net as natively as VB, VFP religion will be gone.

Playing with .NET and being a CLR language are very different things. VFP plays fine with .NET right now.

> We love the VFP community - not C#, not VB community.

What does this have to do with VFP being a CLR Language?

> For Independent Developers, learning another language is not a big issue,
> maybe, but for software development company, it is a BIG one for economic
> reasons.

I don't understand why folks don't get it, if VFP were to become a CLR language you would have the same learning curve as you do with C# today. VFP under the CLR would be extremely different than VFP is today. Also the very things that make you feel so strongly about VFP are the things that would need to be different for it to comply with the CLR.

> Lastly, I think making VFP.Net backward compatible with what it is today is
> not more on a POSSIBILITY issue, but rather a resources issue.

Not one of my arguments against VFP going to CLR is about the technical issue of whether it can be done or not. Also not one of my arguments is about MS resources required to do it. All of my arguments are about the fact that I don't think it should be done.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform