Andrew Lentvorski wrote: > Are objects containers? Do they have their own state? Are they just > collections of functions? Are new objects always created or the old > object mutated? Inheritance? Multiple inheritance? Dynamism? Single > or multiple dispatch? Function call or message passing? Is identity or > class mutable? Are objects a primary type or only the members? > > So what "defines" OO? Hmmmm? > > For every definition of OO you cite, some other language disagrees.
Yeah, this is the pedantic bickering he's talking about. ;-) The essence of OO has nothing to do with containment or lack thereof, inheritence, multiple inheritence, dynamism, dispatch, mutability or the primary type argument. Those are all little details that don't really matter in the grand scheme of things, and to a certain degree those that bicker about them fail to see the forest for the trees. In fact most of what you are arguing about are design points in building an OO programming language, which is one of many tools for helping one do OO programming, but is not in and of itself OO programming. Indeed, it is entirely possible to do OO programming without such a tool, and it is unfortunately possible to not do OO programming with such a tool. The essence about OOP is recognizing the advantages (hard core FP types might argue it is "failing to recognize the disadvantages" ;-) of binding data structures and the operations on those data structures together in to objects (and no, that doesn't necessarily mean objects have their own state) and then organizing your program around objects and their relationships between one another. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
