On Wed, Apr 22, 2009 at 12:09:28PM -0500, Shawn Walker wrote: > 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.
"Largely" refers to the three methods which currently *don't* raise NotImplementedError? Those should probably be fixed. Anyone who wants to be insulated from new methods being added should inherit from NullProgressTracker, rather than ProgressTracker. I don't know that that was the intent, but it's safe, and will do the right thing in this instance -- ignore methods you haven't implemented yet or don't care about. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
