Hi, Walter.

>You're right, the subclasses can be passed, though in such case some other complexities might occur because you don't know the exact type that will be passed (nor the compiler does). At that point all the compiler can do is to check is that only the sepcified class or subclasses have been passed. If in such function you can determine the type of the object (in C++, the Typeoff() function) you can apply casting to call any specific method of that class or use virtual functions in order to let the object to call its own method instead of those of the baseclass.

Well, of course you still can buy you troubles, as usual. But if you keep good OO design principles, you should follow the Liskov substitution principle, which states that subtypes should be substitutable for their base types. If you fail at that, you're loosing polymorhpic power.

In any case, the typing is safe, as the checking is done over the type you declared for the argument, which is your common denominator.

>>>>

>>>>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.
>
>Right, and this can be seen as both an advantage and disadvantage.

Hmmm... I don't see any advantage in allowing unsafe code, but then again, you may prefer to do that.

>>The problem is that complexity and several 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.
>
>It is very simple to create simular problems in strong typing languages as well. Again, if you instantiate or retrieve an object from a comobject and cast it into something invalid, the compiler is not going to object at all, but your program blows up. I don't think we should have the illusion that static typing is going to solve all of those problem and heaviliy rely on the compilers report. Extensive white and black box testing need to be done in both static and dynamic typed languages anyways.

Well, there are some things that you can't do in a strongly typed environment, so while you will always need to test, you at least don't need to write test for things like proper typing issues. For example, when you write unit tests (if you do Test-Driven Development, you do this ALL the time) in VFP you have to take i consideration to add some tests for type safety, while you don't need to do that in Java or C#. In fact, if you have the good practice of asserting the parameters you receive, in VFP you usually write a lot of assertions to check for the proper types, while in the other cases you just assert ranges.

>I agree, however with VFP in some cases, I've had to use addproperty because VFP 7 (and below) did not allow custom classes for columns and pages, etc. It something like a last resort.

Yes, but it is a kludge, due to a limitation. In these cases, you're entitled to the right to do anything you need, and then hide all this awful stuff. 8-)

>I've simular objection agains the assign and access methods. They really make thing more complicated and are not a good idea when trying to make your source readable. when they're used, it often indicates something wrong in the design.

We differ again. I think that having getters and setters is a great feature and a very safe one. Indeed, having no difference between private fields and properties in the past, make my VFP code have lots of getter and setter methods, but then it could be that we come from different schools. Getters and setters are one of the tenets of objets oriented design.

>However, VFP developer highly value the macro's, eval() and exescript() functions. This makes the language different from many others and give you some flexibility that is not easily implemented in static typed languages.

Absolutely agree. This is something that you really miss when you start using other languages. Being jumping from side to side, I allways "tried" to shield myself to stick to much to some very specific mechanisms. I know dynamic code is nice to have, but when you don't have it, you always find other ways to get the same result. It is a matter of being accustomed. It is not really that you have more power or it is easier. But I agree, it's nice.

>>

YourClass oObject = new YourClass()

>
>>tells you that oObject is an instance of YourClass, no chance of error.
>
>Sure, but then again, that is the responsibility of the programmer. I (and many who are fans of the dynamic typed languages) don't think that there is much difference between telling the developer he has made a mistake at compile time or runtime. Aside, technically it is even possible for a dynamic type language to
go over the source here and report such doubtfull action, raising warnings at compile time or even better, just when the developper is typing the the source.

Well, if you make your compiler smart enough to tell you that you have the wrong type, you made it strong typed! 8-D

>>>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.
>
>Sure, but it takes a lot more programming on the average. What I'm getting at is that VFP has been optimized for data handling, and despite its dynamically typing, there is no static typed language, that just for it static typing is a better choice from a performance POV.

I can't agree with this statement. At all. It seems to me like you're trying to tell me that VFP is absolutely better than other languages in this respect, and I can't believe that. If I am the one writing the application, it could be true, since I could probably write it better in VFP than in other languages (maybe). I guess in your case, you feel absolutely sure that this will be true. But this isn't an universal fact. VFP apps are maybe less that a 3% of all the DB applications around the world, and there are lots of them that are best performers, more efficient, and developed in record times, although the vast majority -we all know this is common in our industry- would probably be sluggish, inefficient, and took centuries to be built.

VFP is the single greatest database programming tool... for xBase developers. And maybe for a lot of newbies or non-professional developers to start building simple applications. But this isn't the same as being the best tool for anything. And I want to repeat again: I LOVE VFP. I used it for years, and I know it far better than any other tool. I'm using a few others, and I feel at home whenever I get back to VFP. But this is me, not the universe.

>And beeing on the database topic. This raises another issue. Since programs have to work with data, static typed language also have to deal with issues of database access. If I'm doing a SELECT * FROM MY table, a static typed language has to deal with the uncertainty of what gets returned, whether you declare the resultset or not at forehand, you're never certain what is going the be returned, therefore making the use of database data in your program more complex and cumbersome (I wonder if the databinding issues have to with this??). In this area there are the same mistakes that can be made by the developper regardless of the static or weak typing.

Well, this is a problem of impedance that trascends -IMHO- this debate. Once again, I'm and OO developer, and form me data access and domain logic are different problems, and mixing them produce a lot of troubles that I don't want to have, no matter if this is VFP or Java.

>As one having no programming experience in .NET, it seems that when retrieving and assigning values to fields in the table static typing is not looking at the type which is bound to a particular field at all (again I might be mistaken here).

You can mix both things in .NET, the same as in VFP, but I won't recommend to do it in neither case.

>IMO, the fact is that even static typed language try their best to enforce typing at compiletime, there are external factors (like COM and Database access) something that has to be dealth with.

Yes, you have a gap between the two worlds to be filled, that present a set of problems. Interoperation is always a problem (believe me, I'm working in a project which is a hell about that), but then having weak or strong typing doesn't make that any different.

>>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.
>
>Like you I try to keep an open mind about it and to find arguments that support both (hence the discussion). Note that I have been programming with static typed languages before and know its characteristics. I now also realize that there are new arguments since the last time I've worked with them, which may or may not be relevant in a certain situation.

Oh, I know your open minded, although strong-typed... excuse me, strong-opinionated. 8-)

And of course I see any good debate as useful. I guess this is one of the higher values of these forums.

Best regards,