RE: [cdt-dev] discouraged access in CDT-plugins

["Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>]

Thanks for your response. I can follow your argument about provisional
API. Also I don't think its really problematic to use internal CDT API
within other cdt-plugins. At the same time there are enogh intern-API
usages that I don't think can be rectified.

My overall intention is to keep the CDT-code clean and in good shape for
updates. As there is never a total agreement on what clean code is, it
is usaually a good idea to decide on a minimal set of rules that
everybody then tries to follow. Because no-one else other than me seems
to support that I will no longer bug you, thanks for your attention,
Markus.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> Sent: Montag, 26. Februar 2007 15:45
> To: CDT General developers list.
> Subject: RE: [cdt-dev] discouraged access in CDT-plugins
> 
> Markus,
> 
> I agree with you that using non-API is bad and I am glad you are not
> using it in your development. I would be happy to do the same.
> But we heavily depend on the Eclipse Debug Platform and it has been
> changing very seriously since 3.0 was released. 
> Initially we had two options: 
> a) wait until the API is stabilized and than make necessary changed
> b) use the provisional API and provide a feedback to the Eclipse team
> We decided to go for the second option which has been discussed many
> times. The provisional API has been changed several times and as a
> result we have had to catch up to it. This applies only to the Modules
> view implementation.
> Apart from this I have found two internal platform classes that we are
> using: 
> - DebugUIPlugin is used to provided a temporary fix for a bug that has
> been fixed lately - in 3.2.2 and it can be removed.
> - SourceLookupManager is used by the CSourceNotFoundEditor and I think
> Ken Ryall can explain why.
> We also use some internal CDT classes but I hope we can come up with a
> solution for these cases.
> Hope this will be helpful to understand the problem.
> 
> Best regards,
> Mikhail Khodjaiants
> 
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Schorn, Markus
> Sent: 26 February 2007 14:19
> To: CDT General developers list.
> Subject: [cdt-dev] discouraged access in CDT-plugins
> 
> Hi,
> In CDT 4.0M5 the plugins 'org.elipse.cdt.core' and 
> 'org.eclipse.cdt.ui'
> did not use any non-API from the platform. I still don't 
> accept that we
> introduce such non-API usage with M6.
> I'd like to understand the CDT-committers opinion on it.
> 
> My thinking is that using non-API is bad because:
> * we loose control about whether CDT 4.0 is compatible with a future
>   minor or even maintainance platform release.
> * if we just add enough of such non-API calls CDT it will become a
>   nightmare to maintain CDT, so if this is really necessary, we
>   should have very good reasons.
> 
> There are actually some rules on using non-API, that were 
> created by the
> Planning Council, I think we should follow them.
> http://www.eclipse.org/org/councils/20070123PCMinutes.php
> 
> Markus.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> -- 
> IMPORTANT NOTICE: The contents of this email and any 
> attachments are confidential and may also be privileged. If 
> you are not the intended recipient, please notify the sender 
> immediately and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium.  Thank you.
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>