<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 7, 2014 at 5:48 PM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
Markus Metz wrote:<br>
<br>
> > If so, I suggest changing that, however invasive it may be.<br>
><br>
> Very invasive.<br>
<br>
</div>Probably not. Admittedly, it would affect a lot of code, but only in<br>
fairly trivial ways. Specifically, all of the "Map" variables would<br>
become pointers rather than structures, calls to vector functions will<br>
have "&Map" changed to "Map", and the open functions will return a<br>
pointer rather than having one passed in.<br>
<br>
Although, we could probably get away with just storing a table of<br>
pointers. In theory, callers might move/copy the Map_info structures;<br>
in practice, they don't.<br>
<div class=""><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> > I'd<br>

> > certainly suggest holding off on any 7.0 release until that's<br>
> > resolved.<br>
><br>
> Hmm. This sounds like synchronizing some basic concepts of the raster<br>
> and vector libraries,<br>
<br>
</div>Not really; it's just fixing a design flaw in the 6.x vector API.<br>
<br>
Apart from the issue of the vector library not having a list of open<br>
maps, another issue is that the size (and occasionally[1] the layout)<br>
of the Map_info structure gets baked into the modules, so anything<br>
which changes the layout of the structure constitutes a change to the<br>
ABI.<br>
<br>
[1] e.g. <a href="http://v.info" target="_blank">v.info</a> references a couple of fields directly, rather than<br>
using the appropriate accessor functions.<br>
<br>
Ideally, the size and layout of the Map_info structure should only be<br>
known to the vector libraries. The public headers should declare<br>
Map_info as an abstract structure ("incomplete type" in C parlance).<br>
<div class=""><br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
> which in turn sounds like something for GRASS 8.<br>
<br>
</div>FWIW, the first 6.0 beta was tagged on 2005-01-12, i.e. over 9 years<br>
ago. Unless there's a reason to believe that 7.0->8.0 will happen<br>
somewhat quicker than 6.0->7.0, 8.0 is too long to wait.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Huidae</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</font></span></blockquote></div><br></div></div>