haitex@pnet01.cts.com (Wade Bickel) (07/02/88)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > Well, I finally nailed down a another objection I have to the OOIPC >system: User perception of operation. > > Under an OOIPC system, the paradigm is, "Please method my object." >This is a perfectly wonderful and useful way of dealing with things. >However, the user's perception of the way things are going to happen is that >he'll say to the machine, "Please method my object," and his object will >come back to him methoded. By and large, he will not understand that >running programs are required to method his objects, and that by methoding >objects, the program's internal state may change. > > This is why I continue to support a PPIPC system, where the paradigm >is, "Program controls program." By saying that, the user is immediately >informed that programs are being manipulated in the system, and that his >actions will affect their future behavior. > > To be fair, an OOIPC system is *exactly* what you want for a >consumer-level machine, since the paradigm is so understandable and elegant. >However, the "problems" outlined above should be addressed before any >serious work on it starts. > Hi Leo, I aggree whole heartedly that the concepts and implementation of IPC need to be worked out in detail before any serious work can begin. However, I find your objection to object oriented programing models a little confusing. For one thing, at least in the model I use, programs are just a type of object, so the distintion between the two becomes indistict. Second, properly written programs could function using an internal level of local variables. Thus, when a second ap- plication calls the object processing routine, the calculations simply effect the new frame of variables, leaving other applications alone. The latter case could be relaxable if desirable, say, by passing non-nil structure pointers to the program. If I understand your posting correctly, perhaps you might think about this line of thought. All elements of the system can be made into objects, and these can all be broken in to either verbs (code) or nouns (data). Thus, if the user wants to perform an action, he/she can simply select sequences of objects in a sensible manner. This is the path I think should be taken, and at it's root would be the concept of interactible Abstract Data types. My current thinking is that the first need is an IFF format for abstact data types, an abstract type being one which has no type. Of course, given the necessities of loadable code on the Amiga this is not so simple. Have fun, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM