<div dir="ltr">I think that it's better to hide implementation details such as the Map_info structure, then we don't have to worry about user code making unexpected changes in the Map_info structures. As long as we keep track of open maps, close/delete them when needed and implement the accessor functions, the user doesn't need to access Map_info, I think. Are there any good reasons why we have to expose the Map_info structure to module developers?<div>
<br></div><div>Huidae</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 12:01 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
Huidae Cho wrote:<br>
<br>
> Why don't we keep an array of Map_info only internally (private to<br>
> libvect), just like R__.fileinfo, and use an integer map descriptor at high<br>
> level? Then we can implement accessor functions, only through which high<br>
> level routines can read/write map properties.<br>
<br>
</div>It doesn't necessarily have to be an integer (although that would<br>
avoid the issue of code bypassing the accessor functions and<br>
dereferencing the pointer locally).<br>
<br>
The fact that an integer is used for raster maps is largely a<br>
historical accident. Prior to 7.0, the "descriptor" was the actual<br>
file descriptor of the cell/fcell file (hence the common use of the<br>
name "fd" for the variable holding the descriptor). As file<br>
descriptors are small, non-negative integers, this could be (and was)<br>
used as the index into a table which held other information about the<br>
map.<br>
<br>
In 7.0, the "descriptor" is only the index into the table<br>
(R__.fileinfo[fd]). The actual file descriptor for the cell/fcell file<br>
is stored in R__.fileinfo[fd].data_fd. This avoids wasting a slot for<br>
each open file which isn't a raster map's cell/fcell file.<br>
<div class=""><br>
> > > which in turn sounds like something for GRASS 8.<br>
> ><br>
> > 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>
><br>
> I think it all depends on how we want to change the vector lib. IMHO, only<br>
> adding an array of open Map_infos would not be very invasive, but<br>
> synchronizing with librast (e.g., using a map descriptor and hiding<br>
> Map_info) would take a lot more work and need to wait until 8.0.<br>
<br>
</div>Provided that modules (or higher-level libraries) don't try to do<br>
anything unexpected with the Map_info structures, we could just keep a<br>
table of pointers.<br>
<br>
Problems only arise if code does something like passing in a pointer<br>
to one structure when opening a map, copying it, then passing in a<br>
pointer to the copy when closing it. With the existing API, this would<br>
probably work.<br>
<br>
I find it hard to envisage code actually doing that, but it's not<br>
something which could easily be checked statically (i.e. by analysing<br>
the code). We'd have to implement the internal table-of-pointers, add<br>
code to check that any Map_info pointers passed to other functions<br>
were already in the table, then run tests (or rely upon the users<br>
reporting any warnings).<br>
<span class="HOEnZb"><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>