From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE t Date: 1996/11/27 Message-ID: X-Deja-AN: 201125595 sender: pcg@osfb.aber.ac.uk references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> <6KRKVf9k3RB@herold.franken.de> <55ud3a$n3e$1@goanna.cs.rmit.edu.au> <56bt0g$jda$1@goanna.cs.rmit.edu.au> organization: Prifysgol Cymru, Aberystwyth newsgroups: comp.object,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk Date: 1996-11-27T00:00:00+00:00 List-Id: >>> "ok" == Richard A O'Keefe 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.