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.