[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] discouraged access in CDT-plugins
|
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
>