The only problem I have with your argument (and it is a very good point) is that, in Java at least, you still must have an object which derives from Object. Even if all the methods are declared static, the object still must derive from Object. This is true even in Perl. As long as you bless a reference, you derive from UNIVERSAL.

In the case of C++, I think that you are more correct. C++ only encourages OO but I am still impressed by the way it only really encourages Abstract Data Types (remember you can over load how operators work) rather than Objects (which lack the ability to act like data types). I realize that I may have to think about the differences between Abstract Data Types and Objects.

In Java you have int, and base types. That't exactly what you said in your initial post, but I fail to see why what is ok with Java (we can use Integer instead of int) is not ok with C++ (we can use Integer instead of int and DerivedFromObject instead of NotDerivedFromObject). Only user-defined types are Objects in Java, I would say it's not enough to fit your first category (at least, real OO languages are probably better examples).

I can see your point and you are correct. I will definately have to think about this to get my story completely straight. Thanks!.

I have a quote from another node, which I thought might be relevant to the current debate. This is really just more information to think about:

Patterns aren't Platonic Ideals: Patterns are real-world observations from a particular development community. The patterns described by the Gang of Four aren't free-floating abstractions that somehow exist outside of time and space and were waiting for us to come and discover them; they're practical responses to various day-to-day challenges, including the limitations of C++. An attempt to document Perl Design Patterns should be looking at the best practices of the Perl development community, not just the parts that resemble a ten-year-old collection of patterns from a different language.