Hi Walter,

Interesting discussion.

>As I've been arguing in the thread above. Compile time is too late. You should be notified of possible mistakes when typing. There is also much to say about what is a strong typed language. In some definitions VFP is a strong typed language and in another C++ is a weak typed language.

>- It offers type checking at compile time, while that actually is too late. It should occur on editing.

And how does that work in a loose language? In VFP there's nothing that can check and make sure your variable is declared as local. Intellisense is of no help here.

You want background compilation - fine. VFP has it and does a pitiful job at it. VB.NET has it and it actually works pretty well. C# doesn't have it and I don't miss it.

Compiling code takes seconds with incremental compilation even for fairly large projects. I rather see a list of errors and not be interrupted while I'm typing my stream of conciousness. And you do get hints for variable declarations and bad syntax as you type in the C# editor even without background compilation. The fact is in C# I can very quickly tell that I have a problem even in the editor when I use Intellisense. Intellisense works against uncompiled code by the way in case you were wondering. So if I create a type variable the editor immediately know the type and provides intellisense. If it doesn't I know that the var is not defined properly or I've mistyped.

But really these are editor issues. Some of this can be done by an untyped language as well, but not all of it and not as consistently (as evidenced by the VFP Intellisense shortcomings).

>One of the problems in strong type languages is that you'll HAVE too declare each and every variable and its type. If you remember Open Word document using VB.NET Thread #990971 Message #990971 you can see what kind of problems it might give, while this is so easy to do in VFP.

I'll give you that COM interop is one place that is not as smooth. But then again there's a lot less need to use COM directly in .NET. For openeing a Word document you either a) import the type library and get strong typing for your COM object or b) you use the Office Tools for .NET which provide complete managed wrappers for all the office applications.

There *are* messy things in .NET like returning dynamic objects thataren't defined in a type library ( like VFP SCATTER NAME Objects ), but there are other ways to accomplish that task that's arguably more up to date such as returning collections of fields. But again this applies to interop which if you are using .NET is something you don't have to do nearly as much as you have to in VFP generally.


>Strong typing is esspecially annoying in using COM objects such as (here it comes again) Microsoft Word.
>
>When I do a
>

oWord = CREATEOBJECT("Word.Application")
>oWord.OpenDocument(cMyDocument)
>oDocument = oWord.ActiveDocument

>
>Do I really want to know all progIDs about the objects in the COM object ?? Do I really care ?? Do I really want to bother using reflection (C#) or set stric off (VB.NET) in order to make it late binding ??
>
>I guess most developers not. They just want to open a word document and do something with it without unnessary coding to do JUST IN SAKE OF THE COMPILER.

You're repeating the same point again.

That's what Intellisense is for. In .NET you'd import the type library and get strongly typed wrapper around the COM object so you get the best of both worlds - strong typing and not having to figure out what's available.

>Again, I think compile time is too late and strong typing is too strict. I don't want to be forced to use strong typing. In the thread above I explained that optional strong typing is a much better idea.

And I don't agree <g>...

>That really means that in VFP if you want to use strong typing you can declare your variables at the top and as you type and you make a mistake in a type (which by the way you not make in most cases when using a type prefix in your naming convention), the editor (yes the editor) should give you a visual clue that something is or might be wrong. A seperate compile switch in VFP might compile the whole project and give you type WARNINGS in stead of errors back.

It'd be nice if that happened but it doesn't. I haven't seen an editor for an untyped language that does this, but you basically get that behavior today in any typed language.

>So in a sense I don't think the strong typing itself has much to do with it. I would call it type checking at compile time, without the compiler refusing to compile at all. If for example I want to write a method that can receive a number of parameters of which the type is not know, I don't have to use method overloading to solve the problem. If I want to include COM objects I don't want to bother declaring variables with the proper progID just because the compiler is not able to check whether the type matches ?? Give me a break.

It looks to me that you haven't used any recent tools that do this sort of thing for you almost automatically.

>I think you are wrong here. In a strong type language you always have to worry about issues that come with strong typing (see MS word example above, method overloading issues, etc). That is why you can be more productive in so called 'weakly typed languages like python and VFP.

Is that the only argument you have? COM Interop? Because that's the only time where this matters. If you're using native types all the type info is available all of the time.

And if you really need to you can use VB.NET with Strong typing Off in separate assembly for handling the 'nasty' COM interop stuff that can't be addressed easily.

And even if you don't the code you write to use indirect referencing with Reflection is not that complicated especially with a wrapper function.

object o = Activator.CreateInstance("Word.Application")

wwUtils.SetProperty(o,"Top",10);
int Top = (int) wwUtils.GetProperty(o."Top");

wwUtils.CallMethod(o,"Open","d:\temp\test.doc");

etc.

Sure it's not that pretty, but it's workable and hardly 'difficult' for the special case that it represents.

>I don't believe that many VFP developers do spend a lot of time on fixing bugs surrounding wrong types. I do believe that .NET, C/ C++ programmers do spend a lot of time to make sure that the compiler does not object and do spend a lot of time working arround issues that don't exist in weakly typed languages.

No because VFP doesn't have typing. Everything is a variant. They do spend a lot of time fixing Syntax and typing Errors. At least I do and I hate fixing those at runtime where there's a good chance I'll miss one in testing.

I think you're supposing C++ which arguably is a very difficult language in terms of typing. But C++ is a much lower level interface than something like C#, Java or VB.NET all of which are strongly typed and provide you high level language features without excessive 'casting' and type coercion required by a low level language like C/C++.


>>I've worked this way for many years in Fox and I've never really thought much about it, but after having spent a significant amount of time in .NET, now when I go back to VFP code I sorely miss strong typing and the true Intellisense that VS.NET offers in the editor.
>
>Well, in what case intellisense is really significantly better in .NET? I do understand that you can use intellisense on defined typed properties, but that is all I could imagine. In VFP I could declare all variables at the top of the procedure and intellisense into any com object as well. Really I don't see much of a difference, except that in VFP you have the freedom not to declare LOCAL oWord as Word.Application. That I don't have intellisense then is my own fault because I did not declare it, but I might choose not to. OTOH, there is nothing in VFP that forces me to use early binding, causing deployment problems when clients do use another Word version. In .NET I either have to set strict off (VB.NET) or jump through the hoops of reflection.

There are many problems with Intellisense in FoxPro in that it doesn't pick up type information properly. For example, the aforementioned THIS. in a PRG file shows you nothing useful about the current class except the base class info. Intellisense doesn't work at all unless the class you're referencing is is loaded into memory and then only if you declare the type ('sort of Strong Typing'). So to get any benefit of Intellisense at all you have to use strong typing work style anyway, except you don't get real strong typing.

Intellisense against a COM object going a couple levels deep, fails unless you reassign the reference. Intellisense against array elements doesn't work unless you reassign the reference. Fox Intellisense gives you NO information about return types (because VFP doesn't have metadata nor a type system).

All of those are easily handled by VS.NET. In addition you get XML comments that are visible with Intellisense so your comments show along with the type descriptions. It works across files in a project even uncompiled files. IS works against any type description even if the hierarchy goes through several collections and child objects because the meta data is part of the application. You change it you see it immeidately. It just works consistently.

And coming back to your point in order to get anything to show in Intellisense for local variables you need to actually declare them in Fox too. So you have a sort of attempt at strong typing, but not really. You do the work but only get partial benefit.

>I really would not call interfacing with MS office rare. And if you deploy such solution to clients running different (but compatible) versions of office you're inmediately faced with this very same problem.

Damn Walter - I'm sorry but if this is your only point it's a pretty weak one given the ways that this can be done in .NET.

>>In addition, strong typing in this respect has the distinct advantage of providing meta data information which is another big advantage of .NET that is often ignored. It provides information at designtime (Intellisense that actually works), and for tools that can look at a DLL and tell exactly what types live within it and what functionality is available for it.
>
>I'm not sure what you're telling here. Can you give a .NET vs VFP example here ??

Say you want to know what members class X has. How do you find that out without an instance in VFP? Or say you have a code generator (like I do in wwSOAP) that wants to create a WSDL definition for a Web Service, so it needs to know what methods are available on that Web Service? How do I do that in Fox? The answer is not very easily - you have to parse source code. There's no way to get type information about an object without running it (or compiling into a COM server and then reading the type library which is what I've done - and even that is very unreliable because unless you are strict you'll get only indescript variants for your types). Or you want to create an XML structure for your object so you can pass it to Web Service?

Ok, that's Fox. Very limited. You can work around this by writing reams and reams of low level parsing code that's a nightmare to maintain and keep up and I've done that.

In .NET I can use Reflection to look at a full type interface by point a file on disk and parsing a simple object model to get at any aspect of an object. I can do this by looking an uninstanitated object from disk, loaded within the running process or I can do it (in the same way) from an live object instance. At any point I know what the signature of everything is. As you can imagine building say a Web Service XML document would be much easier if I had that sort of information for Fox objects. Except - well, in .NET you don't need to do any of that anyway - becauset that mechanism is built in. Web Service proxying and XML Serialization do all the work for doing those things.

These are somewhat low level things, but they are important for plumbing that you may use indirectly.

>This really does not have anything to do with strong typing IMO. The features like intellisense advantages CAN be implemented in weak typed languages as well, just by specifying its type, but withouth the compile time constraint. I'm not saying VFP is a perfect example, but it is certainly an example that shows that intellisense can work reasonable (for most developpers anyways) without beeing strong typed. It is not hard to come up with enhancement requests for VFP10 to make it even better. Good enough to make the it irrelevant in the intellisense discussion.

It has to do with being able to retrieve type information which is very useful if you're building tools and lower level components like frameworks.

>>Personally I'm not looking at another untyped language unless it is for scripting and there is no other choice. The gains in productivity are too major...
>
>I strongly disagree and really have the opposite standpoint. My time is too precious to waste with the utterly stupid things I have to deal with because the compiler objects.

Like I said I think you're making your assumption based on something low level like C++. It's nothing like that in a high level language like C#, Java or VB.NET...


>- It requires more work and typing before you've got something working, which is significant in prototyping. At that stage you realy don't care about strong typing at all.
>- It forces you to go through hoops if you want to use variables of which you don't know the exact type at forehand (late binding COM, method overloading, type casting).
>
>What I see for the future is that weak typed languages will provide features that are used as arguments in favour of strong typed languages, while strong typed language will always carry the burden of doing extra work in order to keep the compiler happy.
>
>Future of weak typed languages:
>- Optional declaring of variables (Already implemented in VFP).
>- Optional type checking at compile time, not raising errors, but warnings.

This is a non feature. If you get a warning - what would you do? Just ignore it? Please...

>- Smarter editors that can visually indicate that a variable has not been declared or is declared in another type as it is beeing used.


In the future we won't have to work, and food will be delivered by naked Bud babes on a beach. Oh and we can teleport anywhere and anytime we want... <g>

The technology to do this is here today, but such an editor or tool doesn't exist and I'd put my money on it that in the near future such an editor won't show up because the popular languages are strongly typed and the high end dev tools are being designed for that...

+++ Rick ---