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

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

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

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

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


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

(1) In Self, it's not who you are _cloned from_ that determines your
    properties, but who _your parents are_.  The nearest analogue of
    a class would be a partial function from parent slot names to
    objects, e.g. the "class" (parent*=o123, uncle*=o125, locale*=o23)

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

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

It seems to me that there may be an equivocation involving the word
"program" here.  Even for C++, it is true that
    "the EXECUTION of a program is a system of interacting objects".
You are saying "even for a prototype based language, a program is
statically composed of classes and methods", but once again, nothing
says that an OO language has to be batch compiled.  In the static
sense which I think you have in mind, no "program" as such need ever
exist.

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

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

I don't think anyone is denying that the "analyse, design static structure,
build static structure, light blue touch paper and stand well back" approach
is appropriate for a very large number of applications and projects.  (I am
reading this in comp.lang.ada, after all, and I wouldn't be using Ada if I
didn't think that was the right way to do some things.)  The point is that
it doesn't _have_ to be that way for _all_ applications and projects, and
there _are_ languages permitting a different mindset.  In particular, I
cannot imagine why anyone would want to rule out meta-design, where your
program _at run time_ constructs new 'OO modules' (whatever they are) with
good interfaces and starts using them.  It's not too much to say that that's
exactly how the Newton works.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.