[climacs-devel] the buffer modification protocol
Robert Strandh
strandh at labri.fr
Sat May 6 18:09:13 UTC 2006
After some thinking (and some sleep) I know think the
buffer-modification protocol was a mistake and that I got it right in
Gsharp.
The reason I think it was a mistake is that several independent
"clients" might want to keep independent information of what part of
the buffer has been modified since "last time" (a concept that depends
on the view) the client was invoked and of what needs to be done to
update this information.
What Gsharp does (Gilbert Baumann made this happen) is that each
client programmatically adds a mixin class to the buffer, and then
adds :after methods on that mixin class for the generic functions that
update the buffer. Thus there can be many independent clients, and
each client can independently capture buffer modifications.
The mechanism that makes this work is that an :around method is
defined on clim-mop:ensure-class-using-class so that whenever the
class (the buffer in this case) is defined or altered, the "stealth"
mixin classes are added in. I must say, I have not had a single
problem with this mechanism over the years I have worked on Gsharp,
and it is a great tool for preserving modularity.
Comments?
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
More information about the climacs-devel
mailing list