Hmm....I'm going to have to respond to this in more detail later
(after I've had more of a chance to digest it). It is intriguing,
though, because I tend to think of nondeterminism as providing a
theoretical basis for analyzing recursion. But you will recall that I
compared OOP to programming space rather than time (the idea being
that a problem is solved by building a network of communicating
objects rather then creating a set of procedural rules of the form
"do this, and then this, and if some condition holds, this, etc.")
But sorting provides a particularly simple case in which we see this
same dynamic. There are well known recursive algorithms like
quicksort, but happens if we unwind the recursion? Obviously, we end
up with an explicit data structure that would otherwise be implicit
in the call stack. To push this a bit further, the essence of data
structures (like balanced trees, say) used in nonrecursive sorting
algorithms is *locality*. The structure is not something that must be
described globally, but the basic organizational rule involves just a
node and some of its nearest neighbors. I'm struggling to come up
with a good theoretical model here, but it seems to me that the
principles of coupling and cohesion that I've been discussing are
just locality in disguise.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The policy of being too cautious is
the greatest risk of all."
--Jawaharlal Nehru
On Jul 12, 2005, at 6:41 PM, Richard G. DAVIS wrote:
Well, Gregory, many folks miss the point about OOP. There is a
simple and
not too abstract characteristic of OOP that distinguishes it from
classical
programming. The rest of the putative differences between the two
can be
recognized as differences in terminology--often just nomenclature,
much of
which serves only the purpose of creating a justifying rationale
for OOP.
What follows is a highly restricted explanation edited to make the
text here
reasonable for an email discussion.
Consider a "master program", one that is not invoked by any other
process.
That master program can invoke one, or many, other programs as the
program
developer chooses.
In classical programming, when the programmer inserts a phrase that
invokes
another program, that is a deterministic construct. The programmer
knows
(or, at least 'should know') as the code is written exactly what
program
will be executed when that phrase is used to control the process.
The sole distinction in object oriented programming is the
possibility that
that same phrase that invokes another program is non-
deterministic. There
is always the 'possibility' that the program that is ultimately
invoked may
be a program about which the programmer has little or no
knowledge. Even
the nomenclature used by the programmer in the master program to
declare the
invoked program may not be that which is used to identify the
program that
is ultimately executed.
In classical programming, when the master program invokes another
program,
the 'message' path between the master program and the invoked
program has a
length of ZERO. One example: the invoked program may actually be
embedded
into the master program by the compilation process, which certainly
qualifies as a message path of length zero.
In OOP, though this may not usually occur in practice today, the
message
path length between the master program and the ultimately executed
subordinate program MAY be longer than zero length. Moreover, the
message
path length and ramifications may differ from one invocation of the
same
named process to the next. It is the fact that OOP allows the
invocation
message path length to be greater than zero which given OOP the
great power
and scope of effect that is at the heart of all else that is
thought to be
fundamental to OOP. From this simple elaboration of program
structure and
functionality flows things like "inheritance". Inheritance is
merely a
system of formalizations that describe how the message path is
governed as
to length and ramifications.
If one restricts the message path length to 'zero' all the semantic
and
functional characteristics of OOP collapse, and you are back in the
classical programming world.
Note that 'encapsulation' is not a distinctive feature of OOP,
although this
organizational technique is given great emphasis in the context of
OOP.
Encapsulation was used (maybe even developed initially) by the ancient
Egyptians to reduce the complexity of social systems to manageable
subdivisions. Encapsulation in software engineering is just as
feasible in
classical programming with subprogram invocations being entirely
deterministic and using a message path length of zero.
There are many other issues raised in the context of OOP that are
mistakenly
presented as special to the domain of OOP, when they are much more
general
and have a life that precedes modern OOP.
Regards,
Richard.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
