[GRASS-dev] [GRASS-SVN] r60054

[Huidae Cho]

On Wed, May 7, 2014 at 5:48 PM, Glynn Clements <glynn at gclements.plus.com>wrote:

>
> Markus Metz wrote:
>
> > > If so, I suggest changing that, however invasive it may be.
> >
> > Very invasive.
>
> Probably not. Admittedly, it would affect a lot of code, but only in
> fairly trivial ways. Specifically, all of the "Map" variables would
> become pointers rather than structures, calls to vector functions will
> have "&Map" changed to "Map", and the open functions will return a
> pointer rather than having one passed in.
>
> Although, we could probably get away with just storing a table of
> pointers. In theory, callers might move/copy the Map_info structures;
> in practice, they don't.
>
> > > I'd
> > > certainly suggest holding off on any 7.0 release until that's
> > > resolved.
> >
> > Hmm. This sounds like synchronizing some basic concepts of the raster
> > and vector libraries,
>
> Not really; it's just fixing a design flaw in the 6.x vector API.
>
> Apart from the issue of the vector library not having a list of open
> maps, another issue is that the size (and occasionally[1] the layout)
> of the Map_info structure gets baked into the modules, so anything
> which changes the layout of the structure constitutes a change to the
> ABI.
>
> [1] e.g. v.info references a couple of fields directly, rather than
> using the appropriate accessor functions.
>
> Ideally, the size and layout of the Map_info structure should only be
> known to the vector libraries. The public headers should declare
> Map_info as an abstract structure ("incomplete type" in C parlance).
>
>
Why don't we keep an array of Map_info only internally (private to
libvect), just like R__.fileinfo, and use an integer map descriptor at high
level? Then we can implement accessor functions, only through which high
level routines can read/write map properties.


> > which in turn sounds like something for GRASS 8.
>
> FWIW, the first 6.0 beta was tagged on 2005-01-12, i.e. over 9 years
> ago. Unless there's a reason to believe that 7.0->8.0 will happen
> somewhat quicker than 6.0->7.0, 8.0 is too long to wait.
>

I think it all depends on how we want to change the vector lib. IMHO, only
adding an array of open Map_infos would not be very invasive, but
synchronizing with librast (e.g., using a map descriptor and hiding
Map_info) would take a lot more work and need to wait until 8.0.

Huidae


> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140508/c0f85fe8/attachment-0001.html>