[
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.
John
At 07:59 AM 4/14/2010, Marc Khouzam wrote:
Hi,
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?
Thanks
Marc
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
