[PATCH][RFC] Support for keyword expansion

Matt Mackall mpm at selenic.com
Wed Sep 21 12:05:57 CDT 2005


On Wed, Sep 21, 2005 at 06:46:07PM +0200, Goffredo Baroncelli wrote:
> 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.

Tough call. What information do you plan to make available with keywords?

-- 
Mathematics is the supreme nostalgia of our time.


More information about the Mercurial mailing list