[vtk-developers] protected private storage class pointers?

[Eric E. Monson]

Hey Marcus,

Thanks a lot for your response. I've been away from VTK for a while starting up some other projects, but it's time to dive back in.

Personally, I'd prefer to just be able to access the internal data directly within derived classes when I'm customizing methods like Paint(). When I need access to something like the vectors of point coordinates in the parallel coordinates plot so I can draw symbols where the points cross the axes, it doesn't seem like something that necessarily belongs in the public API – it's a pretty low-level routine that, in my opinion, can just depend on the implementation details of the base class. But, it depends on your main motivation for hiding the data. I guess if you want to, you could go half way and put in protected accessor methods, but I think a lot of accessors might just unnecessarily complicate the API.

I'm starting with the parallel coordinates code since that's been the toughest case for me (haven't been able to get away with subclassing PC classes – had to go back to vtkChart and vtkPlot).

In reproducing vtkChartParallelCoordinates::Paint() I can get both the Plot and Axes through the public API. The calls to Storage elements that I don't think I can access are: this->Storage->Transform, CurrentAxis and AxesSelections.

vtkPlotParallelCoordinates is a bit trickier. Since Storage is derived from a vector of vectors, it gets accessed directly quite a bit, which somehow makes it seem silly to provide accessor methods:

this->Storage->size()
this->Storage->at(0).size()
this->Storage->AxisPos[i]
(*this->Storage)[j][i]

Let me know what you think. I appreciate you taking the time to consider some changes.

Talk to you later,
-Eric


On May 16, 2012, at 5:30 PM, Marcus D. Hanwell wrote:

> Hi Eric,
> 
> On Wed, May 16, 2012 at 5:18 PM, Eric E. Monson <emonson at cs.duke.edu> wrote:
>> Hey Marcus,
>> 
>> I'm revisiting my subclasses of some of the Charts stuff to see whether I can make it easier to maintain as you guys improve VTK. (I add some members to keep track of another set of selections and I need to customize the Paint() routines to display different annotations and decorations.)
> 
> Sounds great, and I value your input as a user of the chart API.
>> 
>> In some cases (especially with parallel coordinates plot and chart) I have trouble just subclassing and overriding the Paint() routine because I can't figure out how to access the Storage classes from the superclass and I can't seem to access all the data required to paint just through the public API.
>> 
>> So, my question, stemming from my C++ ignorance: Is there a reason you make your opaque pointers
>> 
>> protected:
>>  ...
>>  class Private;
>>  Private* Storage;
>> 
>> "protected" rather than "private"? Is there some way I'm not seeing to access this->Storage from within my subclass (say, of vtkPlotParallelCoordinates) since Storage is protected? And, if not, why not just make it "private"?
> 
> It is the VTK coding style, although I agree with an opaque pointer it
> would make more sense for them to be private. I could enhance the API
> to expose more of what you need though, and I had been considering
> whether an internal header might make sense so that derived classes
> can access elements that are not in the public API.
> 
> If you could let me know what parts of the API you need access to I
> should have a little time to look over this and revisit some of those
> choices. It is great to hear you are still working on some of this,
> and I think having an idea of what is missing from the public API
> would be helpful.
> 
> Thanks,
> 
> Marcus