[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