Subject: Re: Protocols? WAS: Why Arc isn't especially OO From: Erik Naggum <erik@naggum.net> Date: Sat, 15 Dec 2001 03:01:16 GMT Newsgroups: comp.lang.lisp Message-ID: <3217374073660749@naggum.net> * Nils Goesche <cartan@cartan.de> | I know (parts of) Java, C++ and CLOS; but could somebody be so kind | and enlighten me about what ``protocol'' means in this context (or | MOP)? I always thought a protocol is something like Q.931 or X.75 :-) Those are _communications_ protocol specifications. There are many kinds of protocols, but they are all concerned with distributed synchronized state transition and context-dependent information exchange. The reasons for specifying communications protocols with such heavy-handed machinery are (1) that there is high value in conserving bandwidth, and (2) that they must be implementable as completely separate projects. This is not different from specifying functions and data types and state transitions in a single software project. For instance, you can only call read-line on an open character stream, you can call close only on an open stream, etc. These specifications are entirely equivalent to what you must do in a communications protocol. In essence, a remote communications peer may be regarded as an "object" to which one sends "messages" in order to influence or interrogate its state. The "information hiding" aspect of some object-oriented models acutely parallels the design of communicating peers, about which one should not know too much and really not force to change state outside of the protocol. What an object or module or whatever exports may be seen as the elements of its (interaction) protocol. The distinction between a protocol and an API is that the protocol will make states and state transitions explicit, while they are usually hidden in commentaries and error conditions in API. Something designed and implemented as a _protocol_ will usually be much more orderly, simply because the number of states and state transitions are reduced when they are made explicit and visible to the programmer. E.g., global variables scare many programmers because one may change the state of the whole system so easily and it is so hard to restore state. A global variable is hard to model accurately, but this is in sharp contrast to the special variable, which may be regarded as arguments to the functions called inside their bindings, each function propagating the entire set of global bindings in effect when the call is made and models their unbinding accurately. However, most protocols that invent variable exchange fail to implement nesting behavior properly. In fact, nesting and recursion appear to be uncommon in protocols designed by people who prefer a "flat" state space. Numerous programming techniques would be so much more _conscious_ if they were designed as parts of protocols. /// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.