>>How does specifiying 1 property to determine the data type of the key being generated not make a class lightweight??? Sorry, you example here is not a good candiate for inheritance. As for possibilities, how many data types are we talking about here. Probably 2, Int and Char. This is why folks have gotten into hot water with inheritance....
>
>- int
>- Double
>- float
>- Formatted char (insurance polices), which length (4 ...20) ?
>- timestamp
>
>Let's stay awake john, You can't implement all possible situations at forehand. What do you mean with hot water? What's wrong with inheritance?
>

Where talking keys here, primary keys right. Thank you very much, but I think using either int or char will work just fine. If you have some other type of key requirements, my guess is that char once again, will work. As for timestamps, I don't see how that make a good key. I think you have over-complicated this one. And yes, I am wide-awake on this one.....


>Only 2 levels are possible in your case. Besides, you I want two instances of the derived object, how would you handle that, rewriting code ?
>

You mean two instances of the class, right?? I am not sure I understand you question here, but I can live just fine with two levels. If I need another instance, I'll create it. If you want another instance in VFP, you create it the same way.

>One method ! Overwriting functions at the object level does not hide the implementation. Therefore a subclass is more neat.
>

Wrongo.... The code is in classes that implement the interface of an abstract class. Also, you keep hanging on to your inheritance hammer here, which is the wrong tool. Here is a good for you regarding multiple interfaces.

Lets say I have an abstract entity class and an abstract printing class. I can write a customer class that implements both the abstract entity interface and the abstract printing interface. Try this in VFP, and tell me how far you get.


>>How did this evolve to an argument on encapsulation. Based on your design, let's say I needed to query the type of data your key generator produces, before it actually produces a key. How would I do that?

>Why do you wan't to query that ? If you do, just make an extra method or property.
>

Thats bad, very bad design. What you are saying is that your interface needs to change. No Thank-You...

>This example was taken from an error handling mechanism on a 2 tier system, but the same aplies to the middle tier in combination with the UI tier, though it's a bit harder to implement.
>

No it's not. The middle tier just needs to send the correct messages. It is up to the UI-Tier to act on those messages.

>I Guess, you never read Alan Cooper, About Face. Some errors can be solved at runtime by your application, if it's possible: handle it. Don't make the users pay for your weak design. Also when an error occurs don't display some errorbox like: Syntax Error in line xxx. the user can't possible understand what went wrong. Before showing your errors to the user, make them understandable and give the user clear options to what to do next.
>

Please be careful about making cites like this. They can come back to haunt you. In fact, a failed lock or trigger failure is not really an error. It is really a resource conflict issue. It happens to be reported as an error, but it is not a fatal one. Obviously, a failed lock is something that can occur at any time. And yes, I have read Alan's book.

I would argue that anything that could be solved by your app is not really an error. Here is another one, File Not Found. Is it an error? Or is it an exception? There is a difference here. Often, we end up dealing with and working around exceptions. Eventough they may be reported through the same mechanism, exceptions and errors are different.



>Maybe it's because you don't want to understand the point i'm making. Convincing other people, is very difficult job, especially when you're talking to someone who has a know reputation in the fox world and doesn't speak your native language. Maybe you remember the last issue we spoke about: the deleted tag.
>

Yes, I remember. I don't any of it was a revelation, and I still hold on to my point of view on that one. Then again, I don't use VFP as a data store anymore because of having to deal with those issues. That's how I solved that problem <bg>.


>Yep, i've got that hat on, but It's not an issue of thinking out of the box, but rather: Is there room to think out of the box ? I can handle C,C++ and VFP. I can't possible think into VB, if I just don't have time for it.
>

This statement makes no sense whatsoever....


>For all Implementation that I do, I think in pure OO terms. If something isn't possible or handy with inheritance, I'll write it in another way. It keeps my designs pure, understandable and simple. You, on the other hand don't think about inheritance untill you actually need it. Two different standpoint. I'll guess it has to do with you experience with VB where everything HAS to be handled without inheritance.
>

OK... Please provide me with an example of how inheritance helps you with code resuse. If you find yourself overriding method code, and then invoking default behaviors, you are not really using inheritance. Rather, you are working around it. Also, if you are such a pureist, you would not be so quick to have design whose extensibility model is built around adding new properties and methods. The whole concept of programming to an interface is kind of lost there, isn't it.


>
>>You have missed the point here. You have admitted you don't know or understand how VB works. Therefore, I am not going into the details. Suffice it to say that approach would not be any more work, or would require any more maintence than your approach. If anything, inhertiance has the potential to cause more headaches down the road in this case...
>

>That's a very odd statement you're making for someone with your reputation. Can you clearify yourself. I'm sure many OO purists are very curious to your statement.
>

First, I don't give a crap about OO purists. Second, instead of tossing what I have said about INTERFACES NOT INHERITANCE side, put some thought into it. I am not saying to give up inheritance. Rather, I am saying there are some alternatives out there. Being a purist might be your biggest handicap...

>>>Here we have different standpoints. I agree that VFPs OO model is most visible at the UI side. But it's strenghts certainly does not restrict to the UI side. Writing good and workable middletier solutions, requires good design. In my case OO provides me of flexibility for future maintainance and new implementations of certain functionality. Inheritance plays an important role in this.
>
>
>>Keep in mind the only OO element missing from VB is inheritance. In the scenarios you list, inheritance would not be the right course of action IMHO. But, you have your approach, and I have mine.
>
>Again, can you prove your statement on any other things than personal opinions or experience ?
>

Please.... Go look at the code I posted about interfaces and how they are implemented in VB and why implementing interfaces is a better approach to what you are attempting to accomplish.