Replies instream....

>>>>This all becomes a lot simpler in a strongly typed language. The compiler won't even let you try to pass a parameter of the wrong type.
>>>
>>>How strong do you want it? And, are you sure this is good?
>>>
>>>In this case, the parameter is an object - that's its type. Now if your smart compiler is too smart, it won't let you pass an object of wrong class (aside the question of how would it know) or of wrong base class. Then you'd have to apply some VB6 inheritance and overload the method for each class to which it may apply. Bad dreams of maintenance.
>>
>>PS -- I don't think I would ever want a parameter of type Object. That's way too general. You can always overload a method to have the same name and different parameter type(s).
>
>Which is exactly the problem. See below.
>
>>Also, yet another question -- what do you mean by "overload the method for each class to which it may apply"? A method belongs to one and only one class, doesn't it?
>
>For each class of parameter that it may apply to. Overloading was, IIRC, passing different types of parameters to routines of the same name, and each one would take care of its own type. However, if you need to pass an object, it would be way too much code to apply to each possible class of objects to which it may apply. So the compiler can't catch that - or if it can, then you're screwed, having to write/fix the same code over and over for each class of parameters.

Yes, that's what overloading is. In OOP terms it's called polymorphism.

We still have a fundamental mismatch in outlook here. You say if you need to pass an object it would be way too much code to handle each possible type. (You said class but I know you mean type). IMO you never NEED to pass an object. That is just a coding style. I would rather pass a specific type than make the called method figure out what it's dealing with before proceeding. "Hey, method, here's something -- I'm not telling you what so you figure out what it is!" Object is the highest level class in the .NET framework, the class from which all others inherit. I want to avoid working at that high a level if at all possible.

>
>Just imagine a simple decorator pattern, which would recurse through all the objects on a form, and, say, apply local codepage if so configured. It would have to check anything that has font properties (or .font member - in case it's an ActiveX), and set the codepage to it... like this:
>
>

PROCEDURE Cyrillize(toObj)
>	TRY
>		IF PEMSTATUS(toObj, "fontcharset",5)
>			toObj.FONTCHARSET=204
>		ENDIF
>		IF PEMSTATUS(toobj, "fonts",5)
>			ofn=toobj.fonts
>			ofn.charset=204
>		endif
>	CATCH
>		WAIT SYS(1272,toObj)+0h0d+" just won't go Cyrillic, stubborn mule." WINDOW TIMEOUT 1
>	ENDTRY
>

>
>We really don't care what the object is - if it's a contaner, line, custom, shape... it won't have a .charset property nor .font member, g'bye, next. With pemstatus(), getpem() and a few other functions we can write code which applies to a general practice object, not needing to write a version for left kidney specialist. We don't even care what class it is.

Why on earth would you want to call a procedure/method called Cyrillize() for objects that don't have font properties?

>
>Now if I have to lose this just so I can have strong typing, so that the compiler can do some of the work for me... what's the nature of that work? That each variable must keep its type throughout its lifespan? So if I write an equivalent of between(), I need about six versions of it, one for dates, one for datetimes, one for integers, one for floats, one for strings, one for currency (did I forget anything?), or else it will work for one type only, and the compiler will friendly warn me about the error in my ways?
>

Yes, variables must keep their types. I consider that a virtue. The compiler sure can't help you find incorrect assignments if it has no way of knowing what type the variable will be at run time.

Maybe in some cases you will have to write similar methods. I believe the framework has built-in methods for most general operations, so you won't have to roll your own. And when you do, they can be appropriate to the data type.

>Not that I don't know what I'm talking about. I wrote few tons of code in several dialects of Cobol, and PDP/VAX Basic, few hundred kilos of Pascal plus some assembler (Z80 and VAX), and I do remember strong typing and other strict stuff, where you had to do the compiler's work, you had to do the machine's work, because the machines were expensive, compared with your time.
>

I am not suggesting in any way that you don't know what you're talking about. The most I would say is maybe you still think in terms of procedures rather than objects.

>But this isn't '88, this is '08. Interpreted code isn't visibly slower than compiled code. Besides, both VFP and CLR run P-code, not fully compiled. CLR actuall IS a runtime. So, strong typing in dot net language is not a must; it's a political move to embrace/be embraced by those programming purists who swear by strongly typed code. Which may be good for them, because they've adjusted their minds to that strictness, and they routinely do part of (what I think is) machine's job, and take care that their variables are of the correct type, to keep compiler happy and produced code fast (*). I'm just a spoiled Foxer. I was quite happy when I didn't have to care about the type anymore, at least not to satisfy the compiler; only to make my code run. With liberty came that responsibility, and I'm still gladly taking it.
>

There's that conspiracy theory outlook again ;-) Compilers aren't out to get you, Dragan. They actually can help you find mistakes before they happen. MSIL code is essentially compiled code. The CLR (common language runtime) is responsible only for executing the code on a specific platform, not insuring adherence to the source language (C#, VB.NET, etc.).

>>I am immersed in C#, maybe to the point that I am seeing things in C# terms when that isn't really appropriate.
>
>IOW, "a lot simpler in a strongly typed language" is simpler because you can't do heavier things ;).
>(sarcasm misplaced, of course - if I had to do dot net, I'd find a way to do heavy things in it)
>

If you think there's something you can do in VFP that you can't do in .NET, other than handle proprietary DBFs, I would love to hear about it.

>----------------
>(*) Never mind that any of music player, IE running in the background, WE (yep, Windows Explorer), virus scanner, adware scanner, additional browser toolbar(s), uncaught adware, dozen listeners in the tray (or, shortly, notification area) and the firewall consume about twenty times more resources.