I think that I might understand what people mean when they talk about
"protocols", but I am not sure. Note - I'm not talking about the Meta
Object Protocol, just invented protocols.
For example, Flexichain (http://common-lisp.net/project/flexichain/)
talks quite a bit about the protocols for accessing data in a sequence.
As I understand it, a protocol is a collection of classes and generic
functions that define an interface for a particular chunk of
functionality. When you talk about protocols, you are implicitly
ignoring the implementation and just talking about how you'd like to
use the code. Obviously the protocol actually needs to be implemented
to be at all useful, but that is beside the point right now.
Is my understanding about right?
Cheers
Brad
"bradb" <··············@gmail.com> writes:
> I think that I might understand what people mean when they talk about
> "protocols", but I am not sure. Note - I'm not talking about the Meta
> Object Protocol, just invented protocols.
I don't understand this distinction. Why not consider the MOP? It's a
protocol in the Lisp sense. Section 7.1 of the standard, "Object
Creation and Initialization", is another example of a Lisp protocol.
> For example, Flexichain (http://common-lisp.net/project/flexichain/)
> talks quite a bit about the protocols for accessing data in a
> sequence. As I understand it, a protocol is a collection of classes
> and generic functions that define an interface for a particular
> chunk of functionality. When you talk about protocols, you are
> implicitly ignoring the implementation and just talking about how
> you'd like to use the code. Obviously the protocol actually needs
> to be implemented to be at all useful, but that is beside the point
> right now. Is my understanding about right?
I think you're on the right track, but specific classes belong more to
an implementation of a protocol than to a protocol definition. Lisp
protocol definitions are GF-centric.
Zach
Zach Beane wrote:
> "bradb" <··············@gmail.com> writes:
>
> > I think that I might understand what people mean when they talk about
> > "protocols", but I am not sure. Note - I'm not talking about the Meta
> > Object Protocol, just invented protocols.
>
> I don't understand this distinction. Why not consider the MOP? It's a
> protocol in the Lisp sense. Section 7.1 of the standard, "Object
> Creation and Initialization", is another example of a Lisp protocol.
I guess that MOP should be considered, but I don't personally know
enough about it to rule it in or out. I was excluding it because I
thought/think that MOP defines how generic functions/CLOS work, and if
we discussed the MOP we would quickly get above my level of
understanding. If MOP doesn't define how defgeneric/defmethod should
work, and is only to do with the object side of CLOS (see, I'm still
thinking that objects and generic functions are related to each
other!), then I guess I can grok MOP at that level. Ie, it is only to
do with Objects, nothing to do with generic functions.
> > For example, Flexichain (http://common-lisp.net/project/flexichain/)
> > talks quite a bit about the protocols for accessing data in a
> > sequence. As I understand it, a protocol is a collection of classes
> > and generic functions that define an interface for a particular
> > chunk of functionality. When you talk about protocols, you are
> > implicitly ignoring the implementation and just talking about how
> > you'd like to use the code. Obviously the protocol actually needs
> > to be implemented to be at all useful, but that is beside the point
> > right now. Is my understanding about right?
>
> I think you're on the right track, but specific classes belong more to
> an implementation of a protocol than to a protocol definition. Lisp
> protocol definitions are GF-centric.
It would therefore be possible to define a protocol without using CLOS
at all, only using GFs and some other type defining mechanism - CLOS
just happens to provide for a nice way to make types that can be
related in an inheritance graph?
The obvious advantage to defining a protocol is that you should be able
to change the implementation at will, or just hook into little chunks
of it as you need it. What are the disadvantages? Do GF's impose very
much overhead for protocols?
Cheers
Brad
"bradb" <··············@gmail.com> writes:
> Zach Beane wrote:
>> "bradb" <··············@gmail.com> writes:
>>
>> > I think that I might understand what people mean when they talk about
>> > "protocols", but I am not sure. Note - I'm not talking about the Meta
>> > Object Protocol, just invented protocols.
>>
>> I don't understand this distinction. Why not consider the MOP? It's a
>> protocol in the Lisp sense. Section 7.1 of the standard, "Object
>> Creation and Initialization", is another example of a Lisp protocol.
> I guess that MOP should be considered, but I don't personally know
> enough about it to rule it in or out. I was excluding it because I
> thought/think that MOP defines how generic functions/CLOS work, and if
> we discussed the MOP we would quickly get above my level of
> understanding. If MOP doesn't define how defgeneric/defmethod should
> work, and is only to do with the object side of CLOS (see, I'm still
> thinking that objects and generic functions are related to each
> other!), then I guess I can grok MOP at that level. Ie, it is only to
> do with Objects, nothing to do with generic functions.
I think a protocol is something that is more mental than linguistic.
If you put a list of DEFGENERIC's into a file and say, "here's a
protocol," then that's all you need.
Here's an example:
;; define a protocol for retrieving customer information
(defgeneric get-customer-list (data-source))
(defgeneric customer-name (customer))
(defgeneric customer-phone (customer))
(defgeneric (setf customer-name) (customer)
(:documentation "blach"))
(defgeneric (setf customer-phone) (customer))
(defgeneric remove-customer (customer)
(:documentation "flub"))
Now you have a protocol for working with customers. If calling code
relies only on this interface, you can switch backends around at will
without affecting the external interface. If I were making mock
objects for example, CUSTOMER-NAME and (SETF CUSTOMER-NAME) might be
implemented by the :ACCESSOR part of a DEFCLASS. If the customer
information is in a SQL database, then these might call out to the
database and return the values, and potentially cache them.
This is very similar to interfaces in Java. If I limit myself to
these interactions, it makes the client code of this protocol less
dependent on how the protocol is actually implemented.
The MOP, for example, lets implementors (and even lowly end-users)
choose how slots should be stored (e.g. a sparse hash, a vector,
etc.), how method lookup works, and so on. Yet the external interface
can continue to operate as it always has.
>> > For example, Flexichain (http://common-lisp.net/project/flexichain/)
>> > talks quite a bit about the protocols for accessing data in a
>> > sequence. As I understand it, a protocol is a collection of classes
>> > and generic functions that define an interface for a particular
>> > chunk of functionality. When you talk about protocols, you are
>> > implicitly ignoring the implementation and just talking about how
>> > you'd like to use the code. Obviously the protocol actually needs
>> > to be implemented to be at all useful, but that is beside the point
>> > right now. Is my understanding about right?
>>
>> I think you're on the right track, but specific classes belong more to
>> an implementation of a protocol than to a protocol definition. Lisp
>> protocol definitions are GF-centric.
>
> It would therefore be possible to define a protocol without using CLOS
> at all, only using GFs and some other type defining mechanism - CLOS
> just happens to provide for a nice way to make types that can be
> related in an inheritance graph?
Generic functions (in the DEFGENERIC sense, not in the sense of + or
REDUCE) are a fundamental part of CLOS. If you use GF's, you're using
CLOS.
The classes are almost incidental, because all the user cares about is
that the object he or she has will be accepted by the methods that
implement this protocol. The names of the classes involved isn't
important.
> The obvious advantage to defining a protocol is that you should be able
> to change the implementation at will, or just hook into little chunks
> of it as you need it. What are the disadvantages? Do GF's impose very
> much overhead for protocols?
I don't understand the question. Any class is going to be using
generic functions. Protocols are simply a way of documenting what
generic functions are going to provide what behavior.
Protocols are mostly about documentation. The advantage is that you
can now publish that protocol to clients of your class and then not
have to worry about changing your implementation. The user also has a
good idea of what to extend if he or she wants to make changes.
I don't think there are any technical disadvantages to protocols.
There shouldn't be any overhead, since all you are doing is specifying
(to the humans who use your program) what generic functions are
associated with each other and what operations the outside world
should be using.
HTH,
Bill
Bill Atkins <······@rpi.edu> writes:
> Protocols are mostly about documentation. The advantage is that you
> can now publish that protocol to clients of your class and then not
> have to worry about changing your implementation. The user also has a
> good idea of what to extend if he or she wants to make changes.
There is at least one old-timer who, when discussions like this crop
up, rears his head and says "Back in my day, on the Nirvana
EnlightenSystem, protocols were defined declaratively and checked and
enforced in a really wonderful way, and I feel bad whenever I use
Common Lisp because I miss it. Nurse! Where's my pill?"
I can't find it via google, though. Maybe he'll show up again?
Zach
Zach Beane <····@xach.com> writes:
> There is at least one old-timer who, when discussions like this crop
> up, rears his head and says "Back in my day, on the Nirvana
> EnlightenSystem, protocols were defined declaratively and checked and
> enforced in a really wonderful way, and I feel bad whenever I use
> Common Lisp because I miss it. Nurse! Where's my pill?"
>
> I can't find it via google, though. Maybe he'll show up again?
From section 12.4 "A Nongoal: Automatic Protocol Support" (page 218)
of Keene's book "Object-Oriented Programming in Common Lisp":
CLOS does not provide automatic support for protocols. This is an
area that the Working Group deemed experimental and not yet ready
for standardization.
[...]
Currently, the vehicle for defining protocols is documentation.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
On Tue, 24 Oct 2006 21:24:55 +0200, Zach Beane <····@xach.com> wrote:
> Bill Atkins <······@rpi.edu> writes:
>
> There is at least one old-timer who, when discussions like this crop
> up, rears his head and says "Back in my day, on the Nirvana
> EnlightenSystem, protocols were defined declaratively and checked and
> enforced in a really wonderful way, and I feel bad whenever I use
> Common Lisp because I miss it. Nurse! Where's my pill?"
>
> I can't find it via google, though. Maybe he'll show up again?
>
> Zach
Don't know, but Eiffel has a system called design by contract.
In this system each component designes a contract in a seperate language.
The system is then implemented.
Later system the checks against the contact to see that it furfill it.
There's the a article on Design by contract in Eiffel
http://archive.eiffel.com/doc/manuals/technology/contract/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: ···············@space.at
Subject: Re: What does "protocol" mean in CLOS terms?
Date:
Message-ID: <uac3ktqnb.fsf@space.at>
>>>>> "John" == John Thingstad <··············@chello.no> writes:
John> On Tue, 24 Oct 2006 21:24:55 +0200, Zach Beane <····@xach.com> wrote:
>> Bill Atkins <······@rpi.edu> writes:
>>
>> There is at least one old-timer who, when discussions like this crop
>> up, rears his head and says "Back in my day, on the Nirvana
>> EnlightenSystem, protocols were defined declaratively and checked and
>> enforced in a really wonderful way, and I feel bad whenever I use
>> Common Lisp because I miss it. Nurse! Where's my pill?"
>>
>> I can't find it via google, though. Maybe he'll show up again?
>>
>> Zach
John> Don't know, but Eiffel has a system called design by contract.
John> In this system each component designes a contract in a
John> seperate language.
John> The system is then implemented.
John> Later system the checks against the contact to see that it
John> fufills it.
John> There's the a article on Design by contract in Eiffel
John> http://archive.eiffel.com/doc/manuals/technology/contract/
Matthias H�lzl has written a Design by Contract system in Lisp
http://www.gauss.muc.de/tools/dbc/dbc-intro.html
HTH
Roland
Zach Beane wrote:
>
> There is at least one old-timer who, when discussions like this crop
> up, rears his head and says "Back in my day, on the Nirvana
> EnlightenSystem, protocols were defined declaratively and checked and
> enforced in a really wonderful way, and I feel bad whenever I use
> Common Lisp because I miss it. Nurse! Where's my pill?"
Can't a fella take a nap these days?
Bill Atkins <······@rpi.edu> writes:
> Here's an example:
>
> ;; define a protocol for retrieving customer information
>
> (defgeneric get-customer-list (data-source))
> (defgeneric customer-name (customer))
> (defgeneric customer-phone (customer))
> (defgeneric (setf customer-name) (customer)
> (:documentation "blach"))
> (defgeneric (setf customer-phone) (customer))
> (defgeneric remove-customer (customer)
> (:documentation "flub"))
What I left out here is the documentation explaining how to get a
data-source, the guantee that get-customer-list will return a list of
something's that work with the customer-* generics, etc. But that
would be the other key ingredient in making a protocol.
Bill Atkins <······@rpi.edu> writes:
> I think a protocol is something that is more mental than linguistic.
> If you put a list of DEFGENERIC's into a file and say, "here's a
> protocol," then that's all you need.
>
> Here's an example:
>
> ;; define a protocol for retrieving customer information
>
> (defgeneric get-customer-list (data-source))
> (defgeneric customer-name (customer))
[...]
Another example is the CLIM rectangle protocol:
3.2.4.1 The Rectangle Protocol
http://www.mikemac.com/mikemac/clim/regions.html#3.2.4.1
CLIM provides several more protocol examples, see the CLIM 2
specification table of contents:
http://www.mikemac.com/mikemac/clim/toc.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
"bradb" <··············@gmail.com> writes:
> enough about it to rule it in or out. I was excluding it because I
> thought/think that MOP defines how generic functions/CLOS work, and if
> we discussed the MOP we would quickly get above my level of
> understanding. If MOP doesn't define how defgeneric/defmethod should
For MOP nirvana and enlightenment, see:
Open Implementations and Metaobject Protocols
by Gregor Kiczales and Andreas Paepcke
http://www.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web.pdf
If I had to pick a subtitle, I would say "MOPs demystified". Print
the document and read it on your favorite chair in a quiet room.
Well, it worked for me--your mileage might vary.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
"bradb" <··············@gmail.com> writes:
> I think that I might understand what people mean when they talk about
> "protocols", but I am not sure. Note - I'm not talking about the Meta
From Appendix A "A Glossary of CLOS Terminology" of Keene's book
"Object-Oriented Programming in Common Lisp":
Protocol
A definition of the behavior of a set of objects. Some protocols
are intended for programmers who are developing client programs,
whereas other protocols are intended for programmers who wish to
extend a program.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Pascal Costanza
Subject: Re: What does "protocol" mean in CLOS terms?
Date:
Message-ID: <4q74qqFljb03U1@individual.net>
bradb wrote:
> I think that I might understand what people mean when they talk about
> "protocols", but I am not sure. Note - I'm not talking about the Meta
> Object Protocol, just invented protocols.
> For example, Flexichain (http://common-lisp.net/project/flexichain/)
> talks quite a bit about the protocols for accessing data in a sequence.
> As I understand it, a protocol is a collection of classes and generic
> functions that define an interface for a particular chunk of
> functionality. When you talk about protocols, you are implicitly
> ignoring the implementation and just talking about how you'd like to
> use the code. Obviously the protocol actually needs to be implemented
> to be at all useful, but that is beside the point right now.
> Is my understanding about right?
A protocol is a set of functions that are designed to be used together.
A very simple example is a file access protocol, consisting of functions
for opening, reading from, writing to, and closing files. It's important
to consider the set of functions in conjunction because there are
implicit rules how you can use the functions, for example in what order.
In this case, say, you can only read from or write to a file that you
have opened before, and it's typically a good idea to close it in the
end. If you read from or write to a file you haven't opened, you will
get an error, etc.
The notion of a protocol plays a more important role in object-oriented
programming than in plain functional or imperative programming because
you can override functionality in your own code and typically have to
adhere to the implicit rules. There are quite a few examples of such
rules in the CLOS MOP, and also CLOS itself (consider the protocols for
initialization, reinitialization, class change, class redefinition,
etc.). You have to know how these protocols work to be able to write
your own methods correctly. This is independent of the actual object
model - these kinds of protocols don't only exist for generic
function-based approaches but also for more traditional object-centric
approaches. (Consider the interactions between the methods equals and
hashCode in Java.)
A problem in object-oriented approaches is the very fact that protocols
are implicit and are at best described with documentation. There are a
few approaches for handling them explicitly, so that they can be
automatically checked to a certain degree, but as far as I can tell,
they are not good enough for practical purposes.
In functional programming, you would rather use higher-order functions
where you can require that the necessary custom functions are passed
such that necessary "overridings" cannot be forgotten. However, they
have their own limitations, and don't solve the problem of guaranteeing
"correctness."
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> A protocol is a set of functions that are designed to be used
> together.
I would say that a "protocol" is a set of "related" resources that
describe and operate together on/in a well scoped space. Plus
documentation (or some other form of "meta" information) describing
(defining) what the space is and how the resources operate (separately
and together) and how they affect the space.
What constitutes "resources" here, I believe, is pretty open:
functions, macros (if language has them), class definitions, variables
(especially if you have dynamic scoping (special variables)), and even
"external objects" (say, files, repositories, or specific dbs or
something).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com