🚀 go-pugleaf

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