Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
VB, C#, and VFP data handling examples
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Visual FoxPro et .NET
Divers
Thread ID:
01215120
Message ID:
01222996
Vues:
25
I agree 100% with you Rick. Since my first contact with a strongly typed compiler (C++), I've been conviced that the benefits it give far outweight the inconvenients. It is far more efficient to have the compiler check for data mismatch than to wait until runtime.

>The point of using a language like C# or VB.NET is that it's strongly typed and in order for that to work EVERYTHING HAS TO BE strongly typed. You can complain about "ooh I have to use an extra explicit keyword to make this happen", but that's the way it is. Somewhere - either inferred or explicit - the typing MUST be provided. In some cases the compiler can infer - in others (like an untyped DataTable which doesn't have typed data - that data is simply not available until runtime) it can't. Anytime the type can't be inferred you have to explicitly provide it. It is what it is.
>
>If you don't like that approach use a dynamic language (like JScript .NET or in the near future the DLR which can run Python, Ruby, JScript and untyped VB) and you get loose typing and all the development headaches that go with that. In that scenario everything is variants and you get the same unstructured hell that you have in VFP. Or heck stick with VFP since it does exactly what you want.
>
>But you can't have it both ways. IMHO, strong typing way, way outweighs some of the explicitness that is required in some scenarios especially given that in most cases it's merely a matter of using type cast. I've been down this path - I cursed strong typing at first as well, but after a short while its benefits way outweigh its shortcomings IMHO.
>
>Type mismatch errors are amongst the most common errors that I make in VFP code. Misassigning or misnamnig types, refactoring or changing variables/properties in one place an missing in another all of which are RUNTIME errors that the .NET compiler (or any other typed environment compiler) can effectively catch.
>
>It takes a completely different mindset to develop this way because that whole Run to see it fails cycle (barring logic errors) is just not something that I don't have to do in .NET.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform