>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?


>>Also OO hides the actual implementation of the original (thus not the derived) objects. This kind of information hiding is IMO very important.
>>
>
>The VB example I gave also hides the implementation. All I needed to know was the interface.

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 ?

>I could care less what work it does behind the scenes. Keep in mind, you are arguing with me about 1 property.

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

>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.

>One one hand, you discuss middle-tier items. Then, you begin talking about UI elements such as dialog boxes.

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.

>FWIW, what you are talking about here is error trapping. If a trigger fails because you cannot update a record due to a lock or another reason, there is nothing to handle, other than to tell the user the record cannot be updated.

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.

>In other words, it is not rocket science. We did the same basic thing in Fox 2.x, where we did not have OO. For somebody who is trying to pump up the virtues of OO, and why inheritance is so important, you are not doing a very good job.

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.


>FWIW, you don't have to sell me on why OO is important, that is a given. I also think inheritance is important. However, inhertitance, like most things, is not appropriate in all situations. You clearly have your "inheritance always good" hat on here. Time to think outside of the box a bit....

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.

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.


>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.

>>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 ?

Don't get me wrong. I'm not saying that middle-tier components cannot be written without inheritance, but it *CAN* be of significant value. In my case it is; to provide consistency with other components i've written.

Walter,