[GRASS-dev] Re: [GRASS-user] g.xlist/g.xremove addons (C version of g.mlist/g.mremove)

[Michael Barton]

My 2c worth is to give g.xlist and g.xremove sufficient testing to  
make sure that they work OK and then simply replace g.mlist and  
g.mremove with the new C versions. Having g.list, g.mlist, g.xlist,  
g.remove, g.mremove, and g.xremove is confusing.

Furthermore, for GRASS 7, I'd recommend merging what are now g.list  
with g.xlist and g.remove with g.xremove.

Michael

On Sep 6, 2008, at 11:15 PM, <grass-dev-request at lists.osgeo.org> <grass-dev-request at lists.osgeo.org 
 > wrote:

> Date: Sun, 7 Sep 2008 02:15:01 -0400
> From: Huidae Cho <grass4u at gmail.com>
> Subject: Re: [GRASS-dev] Re: [GRASS-user] g.xlist/g.xremove addons (C
> 	version	of g.mlist/g.mremove)
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: GRASS developers list <grass-dev at lists.osgeo.org>
> Message-ID: <20080907061501.GA31420 at geni.home>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Sep 06, 2008 at 10:05:08PM +0100, Glynn Clements wrote:
>>
>> Huidae Cho wrote:
>>
>>>> If we decide to keep the script versions as a fallback, those  
>>>> will be
>>>> replaced with Python versions in 7.x, so they can be changed to use
>>>> extended REs (the shell script uses sed, which only supports basic
>>>> REs). Or we can make the C versions use basic REs for -r and add  
>>>> e.g.
>>>> -e for extended REs.
>>
>> FWIW, I've done this; -r uses basic REs, -e uses extended REs.
>>
>>> I didn't mean whether or not we need to keep the script versions; I
>>> doubt the need for fallback versions.  What I suggest is to remove  
>>> the
>>> script versions (already done)
>>
>> The script versions are still there, and should be kept until we're
>> sure that there aren't any problems with the C versions (e.g. whether
>> the configure checks for the regex functions are sufficient).
>>
>>> and "rename" the C version of
>>> g.mlist/g.mremove to g.xlist/g.xremove as its current name g."m"list
>>> (modified g.list) is somewhat awkward compared to g."x"list  
>>> (extended
>>> g.list).
>>
>> Renaming them means that any scripts which use them will need to be
>> changed, documentation needs to be changed, etc, which seems like
>> gratuitous incompatibility.
>>
>>> I don't think it's a good idea to have two flags for basic and  
>>> extended
>>> REs unless grass7 should keep backward compatibility.
>>
>> We don't have to keep compatibility, but that doesn't mean that we
>> break things without reason.
>
> Original g.xlist/g.xremove are not compatible with their script  
> versions
> because these modules support only extended REs with -r flag and I
> didn't see the need for two regex flags.  Having one flag for just
> extended REs would be simple and straightforward, and could be a good
> reason for incompatibility.  Just my two cents.
>
>>
>> AFAICT, the new modules provide exactly the same functionality (and
>> with the same names) as the existing scripts. Anything that worked
>> before with the scripts should continue to work with either the
>> scripts or the C modules.
>
> If we decide to have fallback scripts, yes, the both versions should
> provide the same functionality.  If we decide to drop the scripts, I'm
> not sure why we cannot have just one flag for extended REs and break
> things for the above reason.
>
>>
>> Except for one thing: the g.mremove script has dview= rather than
>> 3dview=. The C modules has 3dview=, and both versions of g.mlist use
>> type=3dview. I'm not sure if there's a reason for this, or if it was
>> just a typo.
>
> The very first version had 3dview=, but I don't know when it changed.
> Probably, when we added g.parser's GIS_OPT_ feature?
>
> Huidae
>
>
> ------------------------------
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> End of grass-dev Digest, Vol 29, Issue 16
> *****************************************