From: topmind on 10 Jun 2005 00:22
> Topmind, nobody is going to respond to statements like
> this, because everybody is going to assume that you
> haven't done your homework and
> won't understand the response anyway. What
> would be the point?
Science is independent of me. Just produce solid
evidence or stick your OO braggin' where the sun ain't
shine. In other words, a place as dim and smelly as your
> 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. I *already*
agreed OO is good for device drivers. But so far it is
a one-trick pony. Make that two trick: Device drivers
What about something like an airline reservation
system, a student grade tracking system,
and inventory system, a finance estimating system,
etc. Maybe they are not glamorous or fun, but THAT
is the kind of thing that most developers work on.
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.
From: topmind on 10 Jun 2005 00:46
> You may investigate this by looking at the source code of this
> particular program. You can download it at www.fitnesse.org.
I see things like socket examples.
Regarding your wiki example, I actually wrote my own wiki about 5
months ago. At first I decided to use files instead of a RDBMS for the
hell of it. But, I wanted to keep open the possibility of later
switching to a RDBMS. Thus, I considered the idea of a generic wrapper
around the "persistence mechanism" (cough). But then I realized I had
to make it rather low level to deal with a lot of crud that RDMBS take
care of for me. I gave up the generic idea, tossed the wrappers, and
the code was smaller can cleaner.
Things like *concurrency*, searching, and cross-referencing were made
pretty simple by the RDBMS. A generic interface that can handle 3 of
files, RDBMS, and RAM is going to be bloated and end up reinventing a
database more or less anyhow. You essentientally wrapped away from
RDBMS by almost building a DBMS of your own. Not very good "reuse" if
you ask me.
RDBMS are more than just a "persistence mechanism". They are "attribute
managers", and if you know how to use them properly, they handle a lot
of grunt-work for you.
A RDBMS *is* an interface, by the way. Think about that long and hard.
From: Rob Thorpe on 10 Jun 2005 04:18
> Rob Thorpe wrote:
> > What you've written above gives a basis for understanding the problem.
> > But you've missed an important part, to have an object-orientated
> > program you need data and subroutines connected together in some entity
> > called an "object" or "class" depending on the terminology.
> "I can identify Encapsulation and Inheritance as aspects of the 'leverage'
> term in my definition. They help make fOO integral to a system."
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.
> > 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.
> OO programs (and fOO programs!!) enable the Liskov Substitution Principle.
What does the Liskov substitution principle have to do with anything?
A program like that I describe could fulfill the Liskov substitution
principle, or it could break it, it's beside the point. Of course with
a complex enough pattern of inheritance and complex enough object
behaviour it becomes hard to obey it (or indeed do much useful) without
> But, agreed, some textbooks are lame.
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.
> > The books I have read and the programmers I have known in the past have
> > always used OO in the way I do above, not tying it to polymorphism.
> > Maybe terminology is simply different in the field you work in,
> > terminology in OO tends to be confused, but it is different from common
> > usage.
> My field is The Church of the SubGenius. I am a disciple of Bob. ;-)
Ah, that explains a lot. Personally, I worship at the church of the
four X's (at least when in Australia).
From: Dmitry A. Kazakov on 10 Jun 2005 04:44
On Thu, 09 Jun 2005 16:13:48 -0500, Robert C. Martin wrote:
> 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.
Isn't it rather strong typing?
The definition "one interface, many implementations" is IMO more
consistent, though admittedly vague. What you describe is rather a "strong
typed" reaction to polymorphism (of objects and methods), i.e. dispatch.
> 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.
Ooch. Can a goal of software design/structuring/etc be "calling functions
through jump tables"? You belittle OO! (:-))
Dmitry A. Kazakov
From: Gerry Quinn on 10 Jun 2005 06:19
In article <Vx0qe.6494$_A5.5126(a)newssvr19.news.prodigy.com>,
> Gerry Quinn wrote:
> > > Or do you still claim OO is not about polymorphism?
> > Yes.
> Then I pick a new word, fOO. The definition of "fOO" is "a style of
> programming that leverages jump-tables, or their equivalents, to bind
> behaviors to messages at runtime."
Behaviours of what? Messages to what?
input "English or French?", lang$
langid = 0
if asc( lang$ ) = 'f'
langid = 1
if langid = 0
print "Click to play music?"
print "Clic pour exÃ©cuter la musique"
if langid = 0
That seems like an example of fOO in action. The run-time behaviour of
the program is bound to the input message, using the equivalent of jump
A bit messy though. If I didn't have objects, I could still do fOO in
more complex cases, but I would soon have even worse spaghetti.
> With this word fOO, I can identify BASIC as "not fOO". VB Classic is "almost
> fOO", and VB.NET is "fOO".
> I can identify a program written in Smalltalk that stuffs all its statements
> into one big unstructured method as "not fOO", and I can identify a program
> written in C that uses pointers to functions stored in structures as "fOO".
> I can identify Encapsulation and Inheritance as aspects of the "leverage"
> term in my definition. They help make fOO integral to a system.
How so? It seems to me that these object features are useful in
practice if you want to do fOO on a C-like language. They come first.
BASIC can do fOO just fine. But fOO on BASIC doesn't look much like
anything one would want to do.
> My word fOO is easy to apply, because it's narrow. Find the jump-table, or
> equivalent, and we got fOO.
> My word fOO is distinct, meaning any two engineers can agree independently
> whether a system has my fOO.
> The easy and distinct properties together lead to a third property. Because
> fOO relates to very important programming topics, and because two engineers
> who know my definition of fOO can say "fOO" to each other all day and know
> what each other mean, that makes my definition useful.
> Definitions should be easy to apply, distinct, and useful.
> In terms of "correct", what is the difference between my word "fOO" and this
> "OO" word you use?
fOO doesn't have anything to do with objects. They aren't even on the
same planet. The only connection seems to be that you have discovered
that OO allows you to do fOO better than in the non-OO example above.
But it allows you to do lots of things better.
- Gerry Quinn