RE: [cdt-dev] API question

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> Sent: Wednesday, April 14, 2010 9:14 AM
> To: CDT General developers list.; 'CDT General developers list.'
> Subject: 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,

I would like to avoid that, to be nicer to our users.

> or go the route you say you didn't want to go down. 

I realized I can't even make my classes internal, because
part of my interface is being used by existing public classes :-(

> Or, of course, really try hard not to change those 
> methods after Helios introduce new variants in a backward 
> compatible way.

I guess that's the one I'll try to follow.

Thanks

> 
> 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
> 
>