[PATCH][RFC] Support for keyword expansion
Goffredo Baroncelli
kreijack at libero.it
Wed Sep 21 11:46:07 CDT 2005
On Tuesday 20 September 2005 13:41, Goffredo Baroncelli wrote:
> On Monday 19 September 2005 23:05, Matt Mackall wrote:
> > On Tue, Aug 30, 2005 at 09:29:38PM +0200, Goffredo Baroncelli wrote:
> > > Hi all,
> > >
> > > the patch below is an initial support for a keywords expansion framework.
> >
> > Can you rework this as a generic filter script for contrib/?
>
> I will see if it is possible; if it is possible to get the information
> in a efficient way form an external script, it shouldn't be problems.
Hi Matt,
I review my code and the code of the filters; I find a problem: you perform the
filtering at the wread()/wwrite() function. But at this level
the code is not aware of the revision of the data processed. So I found
the following solutions:
a) add more parameter to the wread/wwrite functin as filerevision
cons:
- a low level code have to manage a high level information
pro:
- is the fastest/less invasive solution
b) move the filter at the level where the wread/wwrite function are called
cons:
- is an invasive solution, everywhere a wread/wwrite function is called,
it have to be implemented a management of the filter/keyword expansion
- the filter implementation is less natural than the actual implementation
pro:
- the low level code doesn't manage the high level information
c1) create a wrawpper class or a wrapper functions which manage the filtering and the
keyword expansion
cons:
- every wwread/wwrite have to be changed in the new style call
- the simple model of filtering is moved to a higher level
pro:
- the different layers don't exchange too much information
- is clear to the programmer that it is performed a more sophisticated
function than a simple write/read
c2) same as c1, but the filter code still be in the wread/wwrite function; instead the
keyword expansion code is managed with a function/class wrapper; it is similar to my old
patch
cons:
- every wwread/wwrite have to be changed in the new style call
pro:
- the different layers don't exchange too much information
- is clear to the programmer that is performed a more sophisticated
function than a simple write/read
- the simple model of filtering is hide at the low level
b) is the worse solution; I prefer the c2: to separate the keyword expansion and the filtering;
in fact I think that the keyword expansion need some information that the filter _don't have_
to manage, so the two layer have to be separated.
Comments are welcome.
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack @ inwind . it>
Key fingerprint = CE3C 7E01 6782 30A3 5B87 87C0 BB86 505C 6B2A CFF9
More information about the Mercurial
mailing list