On Sat, Mar 22, 2008 at 08:46:03AM -0700, SJS wrote:
begin quoting David Brown as of Sat, Mar 22, 2008 at 12:33:15AM -0700:
On Sat, Mar 22, 2008 at 12:22:55AM -0700, [EMAIL PROTECTED] wrote:
>IMHO the essense of OOP is organizing related functions and data into
>distinct units. We call these data-function blobs "objects".
Actually, that almost entirely misses the point of OOP. I would call that
more something like modular programming or structured programming.
Um, no, that's the key and the crux.
It's important, key and crux, but not of OOP. There are languages that
have outstanding organization and structure without being OOP. I think of
something like SML or Haskell.
It's useful, and it's powerful, but it's not what makes something OOP.
The difference is that (in OOP) if my code is handed a data structure,
the behavior is available... I don't have to find the function that knows
how to handle THAT data structure. It's there "in the object".
Oddly enough, that aspect isn't what makes it OOP, and isn't even
necessary. In CLOS, the methods (generic functions) are not part of the
class or the structure. Classes have their slots and inheritance
completely independently of generic functions. It's actually much more
powerful than most OOP languages because the programmer can add new methods
to existing classes and systems. The organization that most OOP languages
provide can end up being a hinderance as well.
A real common example of this is that I'm implementing something that wants
to encode data. I'd like to be able to encode basic types as well
(integers, strings, etc). In a classic OOP language, unless the original
designer thought of adding an encode method to every basic class, I have to
wrap all of the basic classes in my own classes, just to get this
functionality.
In CLOS (Ada as well), I can write my own methods and provide
implementations for integer and string and so on.
So, yes, you potentially lose some of the gathering of everything together,
but sometimes it is better. Sometimes, the OOP model forces things to be
put in awkward places, just because all of the methods of a class have to
be together.
Mostly people list their favorite language features, regardless if
whether or not it is necessary.
- organization, as you have mentioned.
The *essential* one, I argue.
Except that there are languages that are widely considered OOP that don't
do this (CLOS). There are also languages that have heavy organization
support, but aren't considered OOP (Haskell). This means that organization
is not an essential part of OOP.
- data or structure inheritance. Allowing subtypes that contain the
fields of parent types with possible additional fields added.
And then there are languages like Self that don't have classes, and
thus no "inheritance"...
There's also the notion of duck typing, where the types are defined by what
the object respond to, not how they fit in an inheritance hierarchy.
Perhaps inheritance is not essential to OOP either?
Paul Graham, in ANSI Common Lisp, argues that the separation of classes and
objects is merely an optimization, and not necessary. There are a few
things that can be done when the methods are part of the objects themselves
instead of the classes, but it is more efficient to have the types
themselves be objects, and have the normal objects merely refer to their
own types.
What is essential is dispatch. Whether that is done through inheritance,
duck typing, or prototypes, it still seems to be considered OOP.
- Dynamic dispatch. Probably the most important part. Allows calls to
be generalized
C++ uses static dispatch by default, doesn't it? If you write a C++
program and never define a virtual function, is your code necessarily
not OO then?
Yes. The static dispatch of C++ is an optimization where the programmer
can specify the parts of the system that aren't OOP, and are basically just
using the encapsulation support of the language.
I'm trying to think of an OO language that doesn't have *any* dynamic
dispatch, and failing, so I think you're right (and I also think this
falls out of "data + behavior").
"Features of many OO languages" != "Features of OOP".
But features of languages not considered OOP does teach us something about
what people consider essential to OOP.
An interesting point: Haskell does have polymorphic dynamic dispatch (they
even call them classes). But most do not consider it OOP because the
inheritance has to be done manually. It has the type-hierarchy part of
inheritance, so you can use a more specific object than a method expects,
but you have to spell out all of the methods and name the inherited ones
instead of getting them automatically.
The problem with all of this is that there are all kinds of useful things
that people lump in with OOP and then immediately assume that "non-OOP"
languages don't have these features. When people talk about need OO
design, they often aren't meaning that it has to have dynamic dispatch and
inheritance. This kind of design could just as easily be implemented in a
language that has good abstraction and encapsulation.
David
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
