On Wed, May 7, 2014 at 5:48 PM, Glynn Clements <gl...@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 <gl...@gclements.plus.com> >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev