Tom Mueller wrote:
Any class that is referenced via any parameters or return values from the public API (the api module) is also part of the public API. The 3rd parameter to the ImageInterface constructor is a ProgressTracker object. So this exposes ProgressTracker as part of the public API.
Not quite. The progresstracker, despite its exposure, has never been declared to be a part of the public client API, although it obviously needs to be at some point, but right now there are no guarantees surrounding it. Of course, technically, since pkg(5) isn't a reviewed project, there are no guarantees surrounding it period.
I might also point out that we've made several incompatible revs to the public pkg.client.api over the last six months.
...
I would suggest modifying the new methods within the ProgressTracker class so that they just return rather than raising a NotImplementedError. If someone is interested in doing something for those methods, they can be overridden in the subclass. If not interested, the subclass doesn't need to do anything.
That would make it largely inconsistent with the existing ProgressTracker implementation (and completely in the case of catalog process). I'm not the one that designed the ProgressTracker class, so I don't feel qualified to make that decision.
My own feeling is that it should be an "all or nothing" approach and that it needs to be documented in the class so that when this question is raised again the answer is already known. That is, should the base class simply be a set of stub methods that subclasses optionally override, or should the base class be setup so that subclasses have to fully implement the underlying methods?
Of course, the answer to this also depends on when and how the progresstracker is made part of the client API, etc.
Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
