From: Ian S. <ian...@st...> - 2006-01-06 08:55:12
|
Rob Radtke wrote: > Hi Ian, > I can definitely appreciate your desire to keep the API simple. In this > particular case though, it is relatively simple and effective for the base > class (vil_image_resource) to provide default implementations of the > current_image* functions. Sorry about this: My problem is that most additions to the base class API can have an "in this case" argument. If you want to have a common base class for handling multiple images I would much prefer one of the solutions below. Your solution may make life slightly easier for you - but at the expense of complicating a simple representation of an image and confusing it with videos, pyramids, etc. 1. An additional class that contains a vil_image_resource - generally the base way of solving this problem - but it doesn't play well with the vil loading framework. 2. Use a mix-in pure abstract class (e.g. vil_multi_image) with the relevant API (in the style of Java interfaces) If the unwrapped vil_image_resource_sptr can be dynamically cast to a (vil_multi_image*) then you have you control - if it can't then there is no multi_image support - This approach is elegant and can be used to add multi-image support to other objects. - on the downside I believe VXL core currently has a prohibition against multiple inheritance which would need to be rewritten to allow interface style mixins. 3. Use an intermediate base class vil_image_resource -> vil_multi_image_resource -> vil_nitf_image -> vil_tiff_image Again, if you can successfully dynamically cast the unwrapped vil_image_resource_sptr to a vil_multi_image_resource then you can use that API. Although I still believe that any of these solutions are premature in the face of only one vil file format actually handling multiple images. These implementations are below. By doing this, > subclasses that don't support multiple images per file don't have to do > anything. > > Regardless, I'm more than happy to defer to your judgement on this issue and > do not mind removing these functions from vil_image_resource. I'd do it > immediately, but don't want to interfere with Joe's on-going development. > > Rob > |