From: Gerry Quinn on
In article <1118353502.073242.303320(a)>,
robert.thorpe(a) says...

> > In terms of "correct", what is the difference between my word "fOO" and this
> > "OO" word you use?
> Not responding for Gerry Quinn, here's how I see it:
> By your definition this program is not fOO, I would agree with that.
> However, by the normal textbook definition of object-orientation this
> program is OO.

I went the other way, making a fOO program that is not OO. But your
way works too ;-)

- Gerry Quinn
From: Gerry Quinn on
In article <24cha1pv4rdsg7meuv0nle0h89i5pv4q9e(a)>,
unclebob(a) says...
> On Thu, 9 Jun 2005 12:42:11 +0100, Gerry Quinn
> <gerryq(a)> wrote:

> >To say "polymorphism is present in all OO incarnations without
> >modification" is merely to say that you have defined it more vaguely
> >than encapsulation and inheritance.
> I don't think so. Polymorphism is the ability for an object to
> respond to a message in a manner that is consistent with it's type.

And here's the point: in many circumstances, you know perfectly well
what the type is, so you don't need any special mechanism for
polymorphism. Yet the encapsulation of data members and functions, the
availability of inheritance - these OO features are present regardless.

Polymorphism is a feature of OO, not OO itself.

> Or, to get very concrete, OO is a way of structuring programs such
> that data structures are manipulated by functions called through jump
> tables contained by those data structures.

How can a way of structuring programs be based on implementation
details of a feature that is not even always used?

- Gerry Quinn

From: Phlip on
Rob Thorpe wrote:

> My point is, it is not necessary to have polymorphism, inheritance or
> jump tables to bind code and data into an object. All that is
> necessary is that the two things are presented together.

The first time in this thread I said "jump-tables" I said "or the

You _do_ mean "bind at runtime", right?

> What does the Liskov substitution principle have to do with anything?

It's co-axiomatic with the fOO polymorphism definition. You could start with
one or the other.

Gerry Quinn wrote:

> Polymorphism is a feature of OO, not OO itself.


(And jump-tables ain't 'if' statements, as any two engineers can easily and
independently agree...)


From: Daniel Parker on
"topmind" <topmind(a)> wrote in message
>> But if you took one of RCM's papers off his web site,
>> and prepared a serious critique that demonstrated
>> both that you understood it and also that
>> you disagreed with it, RCM would very likely
>> respond to that.
> But all his examples are device drivers.

Uh huh.

> I *already*
> agreed OO is good for device drivers. But so far it is
> a one-trick pony. Make that two trick: Device drivers
> and shapes.
> What about something like an airline reservation
> system, a student grade tracking system,
> and inventory system, a finance estimating system,
> etc.

Check out RCM's book Agile Software Development. There are applications of
OO to payroll system, a weather station system, and a system for the
Educational Testing Service. Now, I haven't actually read this material,
but I'm sure if I did I'd find lots of things I disagreed with (I notice
VISITOR appears in a bold subheading), so why can't you do that? Do some
real work, give serious feedback? And as a consequence, be taken seriously?

> I am sick and tired of device drivers, animals, and shapes. I gotta force
> OO out of its comfort zone
> in order to expose it for what it is.

First, you have to understand it...

Daniel Parker

From: Peter Seibel on
"Rob Thorpe" <robert.thorpe(a)> writes:

> The textbooks I refer to certainly aren't lame since they use the
> normally accepted defintion of OO - ie. that written in most books and
> used by most programmers. I have never read a book that ties OO to
> polymorphism as you have tried to, but I would be interested to know if
> such a misleading text exists.

Hmmm. What is this "normally accepted definition of OO" of which you
speak? Anyway, for such a misleading text, try:


in particular Chapter 16:



Peter Seibel * peter(a)
Gigamonkeys Consulting *
Practical Common Lisp *
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Next: Use Case Point Estimation