Protected elements changed back to private?

I just converted my first app to 007 from 0062 and I notice that some members of ofVideoGrabber that used to be protected are now private. for example, bool bInitialized; used to be protected. I made a subclass, threadedVideoGrabber, which relied on this to determine whether or not the threaded function should be allowed to run. There is currently no publicly accessible way to determine if the video grabber has been initialized either.

I don’t know if there are other classes that have been changed to having protected members become private, but I’m wondering what the reasoning behind this change is? Obviously it’s not a big deal on my end, I just changed it back to protected. I’m just curious.

is not a very good practice to allow direct access to members from outside the class even from inheriting classes. the problem is if the api changes and that variable disappears it makes it really hard to maintain backwards compatibility.

it’s always better to provide methods to access that variables. in this case in particular ofVideoGrabber is missing an isInitialized() method

Thanks for the quick reply, Arturo.

I was searching this issue earlier and i found this post which seems to be the point where it initially changed from private to protected. http://forum.openframeworks.cc/t/opesourcery/165/6

I feel like there is a very grey area surrounding the issue of extensibility and backward compatibly. I understand the hesitation to open up internal members that are not part of an external API, but, without protected members there is no option to create a subclass that provides an alternate initialization without somehow calling the original, which may not be ideal in some cases. I suppose it’s easy enough for anyone to just change to protected if they need the access for a project, but it can make sharing useful subclasses more difficult to integrate.

we’ve had some problems with that while developing 007 because some variables like with and height were public, now that ofVideoGrabber doesn’t really initialized the video but relies on other classes the width and height variables aren’t really needed but they have to be there because of bw compatibility.

for what you want to do, actually you should be using aggregation instead of inheritance + inherit from ofBaseVideoGrabber so your new class provides the same api as the original video grabber and can be used anywhere. modifying the internal state of a class even from a child is not a good idea. something like:

  
class ThreadedVideoGrabber: public ofBaseVideoGrabber{  
  
void initGrabber(...){  
grabber.setUseTexture(false);  
...  
}  
  
...  
  
ofVideoGrabber grabber;  
}  

where most of the methods will be something like:

  
  
float getWidth(){  
return grabber.getWidth();  
}  
  

is more verbose but also much more future proof

Yeah, that is how I’ve been doing it, I just ran into a problem here:

  
  
class ThreadedVideoGrabber : public ofVideoGrabber, public ofThread {  
    protected:  
        void threadedFunction(){  
            if(bInitialized) {  
  

where I don’t want to the thread to run if the grabber has not been initialized, but bInitialized is now private. A public ofVideoGrabber::isInitialized() would solve it, as you said.

i’ve added it in the develop branch in git

Cool, thanks Arturo. I’m still intimidated by git and contributing to OF in general. One of these days I’m going to learn it though, I’d love to contribute and give back to such an amazing project that has been so good to me so far :slight_smile: