Hi, Walter.

>In fact of what you describe here above is IMO just a strong point of weak typing. The procedure can now recieve any object of any type and it would work as long as it has a deposit method. So you can just build subclasses of the Account object or other classes with a deposit method as much as you like and it works. With static typing you'll have to use method overloading (or vitual functions in C++) to achieve the same.

No, no, no. With strong typing, you'll declare the parameter to be of Account type (for example) and it would support any of it subclasses, and this is safe. This is one of the basic features of polymorphism. The good thing is that the compiler WON'T llow you to pass anything that's not an Account (at some point up the hierarchy).

>It is the reponsibility of the developer that it won't be called with a parameter of an incompatible object type. I know that anyone comfortable with static typing would raise an eyebrow here, but this is really the other side of the coin. But to answer the question, nothing holds you from specifying:
>
>>

>>lParameters toAccount as MyAccountclass of myclasslib, tnAmount
>>
>>toAccount.Deposit( tnAmount )
>>

Yes, but then again, you can pass a Carrot object and it would simply blow, as this is declarative, but not enforced.

[sip]
>The same applies to simple types as well, and it is the responsibility of the programmer to avoid nonsense (though the code would works). And here again, you specify what is regarded as a strong point of dynamic typing. Please see the code example I send to Rick. You're able to reference objects without knowing its type, which can just have huge advantages when dealing with complex object relations. And with strong typing you're not entirely free of this as well. When doing a CREATEOBJECT() it is the responsibility to cast that into a proper type as well because the compiler won't detect it. Worse, if you cast it into the wrong type library you have an inmediate problem.

The problem is that complexity and severl indirection levels could make not obvious what's what a given method is receiving. In a strong typed language, this is validated an not left to the "programmer responsibility", which can fail.

>>I won't add macro substitution here because it will make things go awry.
>
>Or THIS.AddProperty and evaluate() for that matter.

Yes, all this applies. In fact, I highly discourage anyone to use AddProperty at all, as it iolates the design principle of clearly defined interfaces in your classes.

>So, isn't smalltalk dynamically typed ?? Again this is the argument, I'm not comparing .NET and VFP, but static and dynamic typing. Only using VFP, C/C++, .NET as a reference for examples.

Yes, Smalltalk is weakly typed, but it keeps everything alive all the time, so it can keep track of everything. Indeed, even so you can fall in many traps because of the weakly typing, and it is one of the most debates topics in the Smalltalkers' community.

>

LOCAL oObject as MyClass of MyClasslib

>
>Then intellisense tells me everything that is in.

No, it just tell you what it is supossed to be. Instead:

YourClass oObject = new YourClass()

tells you that oObject is an instance of YourClass, no chance of error.

>>Oh, don't get confused. I'm not talking about you writing low-level language. I mean the intermediate language the compiler translate to before going machine code, and where most optimizations are made. If you don't have strong typing at high level, you can't making come to the lower ones.
>
>Again you dont need to as long as you have runtime type checking (which obviously does not exist in static typed languages). Again, you talk about optimizations, implying performance on non-complex functions. Not something that is really applicable to database development. The things that do matter on database development have been optimized already and its performance is not affected by beeing static or dynamically typed in any way.

Uh... well maybe your are just talking about that kind of applications. I was talking on a wider range. Once again, if the type of applications you do does not require anything more that what you have, it's ok. But this doesn't decrease the value of strong typing itself. It does just on your case, maybe.

>>>What is the reason that early database product like dBase, Clipper, VFP were so successfull ?
>
>>I guess it was because they did hide the complexities of using general purpose languages, when you didn't need all the power and performance the later could provide, and arrive to simple solutions in a short time, what is still completely valid, in that kind of simple scenarios.
>
>In what way simple ?? Name one static type language that could provide the power and performance in handling data even comparable to VFP ??

I don't think this is a language issue, but data access method. VFP has both thing in one package, but I've seen (beside what I wrote which I won't judge) high performance database applications written in Java, C++, C#, and more.

Once again, I think some things could be of little value to you, but it doesn't mean other techniques are less valid. I just think that (for me also) it is difficult to judge how much value one can derive from tools, technologies or methodologies we don't use intensively. I try to keep an open mind about it, as I discovered many times that things that I dimed as irrelevant or unproductive were great once you realize its real power.

Regards,