Will reply to this one later when I have more time. Before I forget, though, we used the word "object" in different ways. An object, lower case, is indeed an instance of a class. I meant upper case Object, which is the root class in the .NET framework.

More later....

>>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).
>
>No, I meant class. If I had to write separate code for the case when the parameter is a textbox, then the same for an editbox, another one for labels... it would take all day. Then next day I'd find a bug in one of them, and would have to repeat the fix in six others, and test all seven. I'd rather do it, you know, the OOP way, have the code in one place only.
>
>> IMO you never NEED to pass an object. That is just a coding style.
>
>Now this is where we strongly differ. You can't do anything more complicated, because you need to know twenty parameters (by position or name). In ADO.net, don't you ever pass a recordset as a parameter? In old ADO you couldn't breathe without doing that. Recordset is an object.
>
>> 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.
>
>I meant "object" as an instance. Is it Microsoft redefining common words again? Last time I learned the meaning of "object" in OOP, it was "an instance of a class". Now it's a top level class... maybe the same as the abstract class in the root of the class set? Didn't mean that - I thought nobody mentions it in that sense except when explaining the whole inheritance in a lecture.
>
>>>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?
>
>Same if I did it on Mars - I just do it on all the objects on the whole form, because that way I don't have to know on which objects to do it, I don't have to go over 300 textboxes and other that may exist on a form, just to check which ones have font properties. That's a machine's job. And I can't do that at design time either, because some things may be added at runtime.
>
>Also, I'm not buying into the idea that I should do that for every class which may need it - too much work, I'd have to repeat these lines for each of them, for no good reason.
>
>What's wrong with passing objects as parameters? Are they equal but separate or vice versa, when compared with other parameter types?
>
>>>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.
>
>Same here. I may have had a couple which changed type, but that was a decade ago.
>
>>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.
>
>Since I didn't have strong typing in the last 19 years, I'm quite used to avoiding that kind of error; still happens once or twice a month, and even that is not with variables, but with fields in someone's table where I guessed it wrong - and strong typing won't help me there, will it? OTOH, strong typing would literally cause a few (or dozens of) new errors, in cases where I changed my mind about a type but forgot to tell the declaration about it, or where I forgot to declare.
>
>>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.
>
>IOW, no decorator pattern, eh, unless it's something already in the box?
>
>>>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.
>
>That was for lurkers out there, who may have missed the introductions :)
>
>>The most I would say is maybe you still think in terms of procedures rather than objects.
>
>Oh I think so much in objects that I love to toss them around as parameters...
>
>>>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.
>
>But then the mistake is defined within the compiler itself, so #define mistake "what the compiler doesn't allow". Strong typing is, IMO, a service to the compiler, not as much to the programmer. I'm getting much more help from the ability to just run a snippet from the command window, without the whole "write-compile-run-enter password-navigate down the menu-start the form-enter values-click save-click yes-wait for debugger to come up" cycle. That's a real timesaver.
>
>>MSIL code is essentially compiled code.
>
>P-code is compiled code. It's not machine code, though; it's the same as an .fxp.
>
>>>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.
>
>See code above. How do you implement a decorator pattern?