Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] API question

This is basically the same dilemma DSF has with the provisional parts of the Flexible Hierarchy. You don't want your public API exposing internal/provisional types. It can use those types, just not expose them. The internal quality is very much viral in that way. The only viable directions I see are to either make the likely-to-change APIs public and bank on the fact that the next CDT release will probably be a major one, or go the route you say you didn't want to go down. Or, of course, really try hard not to change those methods after Helios introduce new variants in a backward compatible way.


At 07:59 AM 4/14/2010, Marc Khouzam wrote:

I have a new interface IGDBTraceControl.  Most of this interface is stable, but
I know that I minor set of methods will most likely change after Helios.

I thought I should put it in an internal package, but when I do that, I get
a bunch of warnings because I'm using some parts of this interface in API classes.
Making all those other classes internal is overkill because they only use the
stable part of the interface.

Any way to deal with this?



cdt-dev mailing list

Back to the top