The term "Protocol"

[Alex Martelli]

On 2004 Aug 02, at 16:44, Aahz wrote:

> [cc'ing Alex so he can jump in if he wants]
>
> In article <mailman.1042.1091409923.5135.python-list at python.org>,
> Bruce Eckel  <BruceEckel at MailBlocks.com> wrote:
>>
>> I know the term "protocol" has been used to describe a language 
>> feature
>> in a number of languages, but since we have no official "protocol"
>> support in Python I'm interested in what "we" mean by this term. I'm
>> going to guess that a protocol is like an interface in Java, except
>> that it doesn't have a concrete definition anywhere, but it is implied
>> through convention and use. Thus a protocol is a "latent interface." 
>> Am
>> I close? I'd like to understand this term better.
>
> Alex Martelli gave an excellent presentation on Design Patterns at 
> OSCON,
> where he made the point that "interface" is roughly equivalent to 
> syntax,
> whereas "protocol" is roughly equivalent to syntax plus semantics.  In
> other words, computer langauges rarely (if ever -- although I suppose
> Eiffel comes close) enforce protocols in any meaningful way.
>
> I'm hoping Alex posts his slides soon.

Sorry, ADSL down, leaving for the Alps tomorrow, emergency netting from 
an internet cafe` at $$/hour.  Hope to have my slides up when I get 
back (Aug 17 or thereabouts).  But yes, what I deduced as the meaning 
of "protocol" from its occasional usage in the literature (about 
components, mostly) is that it adds to the interface (syntax==method 
names/signatures) the semantics and pragmatics ("you cannot call any 
other method after calling close" being more pragmatics than semantics, 
at least in linguistics terms).  Languages do enforce protocols (e.g., 
raise an exception if you do mistakenly call something else after 
calling close), just not "at compile time" (not even Eiffel, where 
contract checking is runtime -- not even Haskell for its typeclasses, 
which is what I believe comes closest to compiletime protocol 
checking).


Alex