Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t

[pcg@aber.ac.uk (Piercarlo Grandi)]

>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.edu.au> writes:

ok> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

piercarl> The observation above is, as per your remark, strictly
piercarl> speaking not general enough; but then just saying "OO module"
piercarl> instead of "class" would give it generality.

ok> Yes, but it would provide generality by means of obscurity and vagueness.
ok> What, for example, is an "OO module"?  I am aware of several languages
ok> having both objects and modules:
ok>  Ada 95 (module=package, object=tagged record instance)
ok>  ISO Pascal Extended with Object-Oriented Extensions to Pascal
ok> 	(module=module, object=object=pointer to extended record)
ok>  Oberon-2
ok>  Common-Lisp/CLOS (module=package, object=class instance)
ok>  C++ (module=translation unit maybe, or better, namespace; object=record)
ok> so the term "OO module" seems to mean something like "module containing OO
ok> components".

Well, I had hoped that it was very clear from the context is that I was
using ``OO module'' in the sense of ``module designed according to the
OO paradigm''. This encompasses, as I had written, both the concept of
class and of prototype (and of actor).

piercarl> For whether class or prototype based, an OO program is a
piercarl> collection of (OO) modules, and values at runtime are either
piercarl> instances of a class or clones of a prototype.

ok> (1) In Self, it's not who you are _cloned from_ that determines your
ok>     properties, but who _your parents are_.

Please reread more carefully the above paragraph: I was not talking of
the properties of a clone, but its instantiation relationship to
``something''. Most definitely in Self like in other prototype based
languages a clone is an instance of its prototype, and not of its
parents, just as in class based languages an object is an instance of a
class, and not of the parents of that class.

ok>     The nearest analogue of a class would be a partial function from
ok>     parent slot names to objects, e.g. the "class" (parent*=o123,
ok>     uncle*=o125, locale*=o23)

I think this point is based on confusing the distinction between
delegation and inheritance for reuse of interface and implementation,
with the distinction between class and prototype as a template for
instantiation.

The ``properties'' (operations etc.) of an object depend on the sum of
the properties of the class parents in (some) class based languages, and
on the sum of properties of the clone parents in (some) prototype
languages; however objects are still instances of one specific class and
of one specific prototype.

ok> (2) The parents of an object can vary through time.

This has nothing to do with being class or prototype based; it has
something to do with the ability to change ``types'' (metamorphism) at
runtime, which is not even unique to Self, or to prototype based OO
systems, or to OO systems.

piercarl> OO programs (as opposed to their executions) do occasionally
piercarl> contain some instances or clones, but this does not justify
piercarl> the observation that "OO programs are systems of interacting
piercarl> **objects**".

ok> It seems to me that there may be an equivocation involving the word
ok> "program" here.  Even for C++, it is true that
ok>     "the EXECUTION of a program is a system of interacting objects".

How? In what sense? How do objects interact in the execution of a C++
program? Are you sure? When I use some sort of debugger to watch the
execution of a C++ program I see threads running procedures in different
modules, those procedures call each other, passing objects as arguments;
I have never seen those objects interacting. It would be interesting to
know what I have been missing.

ok> You are saying "even for a prototype based language, a program is
ok> statically composed of classes and methods",

Not at all: this is presented as a quote, but it is nowhere like what I
have said; please reread more carefully what I have actually written:

  piercarl> For whether class or prototype based, an OO program is a
  piercarl> collection of (OO) modules, and values at runtime are either
  piercarl> instances of a class or clones of a prototype.

ok> but once again, nothing says that an OO language has to be batch
ok> compiled.

Nor have I ever written anything even remotely suggesting this. Are you
sure you have been reading my article? All I am saying is that an OO
program must be composed of modules, such modules may be classes or
prototypes (or actors). I have never stated or implied that such modules
or prototypes should be defined statically or should be batch compiled.

What I am saying is really just something obvious: that programs, and OO
programs no more and no less than others, are descriptions of
abstractions over their executions; therefore they are composed of
``template'' like entities, e.g. modules, types, procedures, that will
be instantiated into objects of various sorts at runtime, but such
objects are not described in the program itself.

A program, being an exercise in abstraction, does not describe a
potentially very large collection of execution objects; it describes
abstract entities, templates that give rise to those. Those templates
can then be dynamically defined, can be interpreted, compiled, or
anything in between; still the program is composed (almost exclusively)
of such abstraction/templates, and not of interacting objects.

ok> In the static sense which I think you have in mind,

This attempt at telepathy unforunately has failed. Please read what I
have written instead of trying parapsychology. I have never ever implied
any static sense; merely stated the obvious, that programs, whether
static or dynamic, are (mostly) composed of abstract entities (modules
for example), not of their instances.

Both abstrations and instances can be created statically or dynamically;
however (by and large) programs are systems of related (I would use
``interacting'') abstractions, like classes or prototypes in the OO
case, or procedures, not of instances; viceversa program executions are
(by and large) systems of interacting instances (threads, procedure
instances, actors, for example), but not abstractions.

Still, as I wrote it, I did not rule out static creation of instances or
runtime creation of abstractions.

ok> no "program" as such need ever exist.

Well, actually it must: for _something_ must be well defined at some
time to be called a ``program''. People write programs, and they get
signed off and released. If we had any sort of General Problem Solver,
the issue of writing and releasing programs would not arise; but then OO
would be largely useless as well, for OO is an idea on how to maximize
reuse in human-written programs. There is no reason to think that
maximizing reuse, or even just maximizing it in the OO way, would be the
right thing to do if the author of the program were a mechanical instead
of a human program synthetizer. Still, at any point in time, even a
program synthetizer must define a currently running program, the one
being executed.

piercarl> While the analysis and design of an OO program may/should be
piercarl> based on some mental image of how it is going to be executed,
piercarl> both activities are really about deciding into which
piercarl> ``encapsulated'' concepts and modules
                                        ^^^^^^
piercarl> to decompose the solution to a problem, and not into which
piercarl> ``interacting'' objects (even if in some languages OO modules
piercarl> are objects, and in some others objects to interact).

ok> Is the Sun "really" a nuclear reactor or is it "really" just a big
ok> ball of hot gas or is it "really" a source of heat and light?

The analogy fails here: for the Sun is a physical entity, and you are
just presenting different views (mental constructs) of it, and none may
be more appropriate than another.

But that an OO program *is* a set of modules is so by _construction_,
and that "analysis and design of an OO program [ ... ] are really about
deciding into which ``encapsulated'' concepts and modules to decompose
the solution to a problem" is not therefore a point of view, but the
construction process that produces it.

ok> I don't think anyone is denying that the "analyse, design static
ok> structure, build static structure, light blue touch paper and stand
ok> well back" approach is appropriate for a very large number of
ok> applications and projects.  (I am reading this in comp.lang.ada,
ok> after all, and I wouldn't be using Ada if I didn't think that was
ok> the right way to do some things.)

Not that I have written any of the sort, but it is an interesting point
of view, and is in fact correct, if one looks at programs as produced by
humans. At some point, if only because one is the author of a program
synthetizer, this is what must be done.

ok> The point is that it doesn't _have_ to be that way for _all_
ok> applications and projects, and there _are_ languages permitting a
ok> different mindset.

Not at all; you are confusing the notions of writing a program, and of
writing a program synthetizer. Some languages allow doing runtime
synthesis and execution of programs, some don't; but in both cases the
program *as delivered by the human* _must_ be statically defined, and in
both cases the program, whether its source is human/static or
mechanical/dynamic, _must_ be composed of modules, and not their
instances.

That human generated program _must_ be static is _unavoidable_, for
humans don't live inside computers and are not part of its execution
environment. (the point about static/dynamic program composition has
been raised by you; I had not in any way restricted my argument
explicitly or implicitly to statically constructed programs, or to those
authored by humans).

That programs, whether generated statically by a human or by a
synthetizer, or dynamically by a synthetizer, must (mostly) consist of
abstractions and not of their instances is also all but necessary, for
the essence of the usefulness of a program is that is it is an
abstraction over all its possible executions.

This applies both to OO and non-OO programs; in the particular case of
OO programs, whether they are statically or dynamically authored, by a
human or by another program, they must be (mostly) composed of
abstractions which are modules, and these modules must respect the OO
decomposition paradigm (encapsulation of all and only the procedures
that access the representation of a single type) whether these modules
are classes, or prototypes, or actors or whatever else.

It *is* possible to write OO programs which _are_ indeed systems of
interacting objects, for example an actor system program that prints the
result of summing 2 and 3, but this is a rather exceptional case because:

  * objects don't interact, even at execution time, except in actor
    systems.

  * writing programs as systems of objects, whether interacting or not,
    is rather less useful than writing them as systems of related
    abstractions, for example because in general there will be many less
    such abstractions than their instances, such being the nature of
    abstractions.

ok> In particular, I cannot imagine why anyone would want to rule out
ok> meta-design,

Who has ruled this out in this discussion? I am not aware of anbyody
having done so.

ok> where your program _at run time_ constructs new 'OO modules'
ok> (whatever they are) with good interfaces and starts using them.
ok> It's not too much to say that that's exactly how the Newton works.

That's perfectly OK. But the program that does this _must_, in order to
be OO, be decomposed in modules that satisfy the OO decomposition
strategy, and so the programs that is generated. Whether the latter, the
output of a programs synthetizer _should_ be structured in the OO way,
or any other way, or structured at all, is a rather interesting question
for which I don't think there are as yet any answers.