Hi martin,

>>I don't mean that. I mean that a routine can be used by more than one unrelated (object) types, like for example:
>
>I understand what you mean, but for me, that violates OOD principles. Indeed, typing is one of its tenets, and that's why strong typing is so important to me. Types convey a lot of information, and provide for the necesary abstraction. In your example, you're being explicit instead of polymorphic.

Ehh, I don't think so. If you do a DO CASE and get the type of the object and cast this opject into this type (or interface) before calling a method or accessing a property, you're indeed beeing explicit.

However, If you just check if a method or property exists and then access it, polimorphism still applies: From the code there is no way to tell which class implementation is used. The object itself does determine that.

>>Sorry I can't see this. Applications are about algortithm AND data, so you'll have to deal with both. This is still the area we (as developers) are strugling with. This is why the OO database was invented. However the OO database never made it because of inherent problems. There is not something universal as a OO SQL or even, on a lower level, an OO alternative integrating to the relational model.

>Well, for me, application is about domain logic. How your domain model persists is another question. So you see, we have quite different basics.

I'm beginning to suspect that we have different starting points here. In application development the main focus is on data and information flow, following the applications architeactual design (in an iterative manner). The application in first place is a data/information management system. The domain logic is of secundary importance and is build upon the first.

I also realize that the difference my be in the type of application. In situations where the domain logic is rather static (e.g. financial, bookkeeping) the focus is more on the domain logic. When doing process controls, scientific analysis when the domain logic itself is far less static (as new techniques or better processes are introduced), the domain data and information is far more static (though new column will be added all the time).

>I mean you can have data access scattered and tangled with your domain logic, or you can have it properly isolated, in VFP, Java, .NET, and any other decent platform. For me, again, the domain model is what I care about, and the back-end is something I have to take in consideration from an architectural standpoint, but not while I go ahead in the development. I think we are more data-centric.

I think we all agree that it for back end data access (In VFP I'm using a lot of cursors in the aid of post processing and datamunging on local cursors also) it should be as isolated as possible. And again the domain model (to me: domain logic and domain data together) might not be as static as you wish. Therefore I'm more focusing on the domain data. And of course you are right the actual technical implementation of the data handling is of secundary concern. However I clueless, as what point you are trying to make here.

Walter,