Question on class hierarchy of CBuildConfiguration

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Question on class hierarchy of CBuildConfiguration

15 knots
Hi gurus,

Currently my code takes a CBuildConfiguration object as an argument in its public API.
CBuildConfiguration is an abstract class and I would like to use an interface instead.
Looking at the class hierarchy of CBuildConfiguration, I can find it implements interface ICBuildConfiguration and interface ICBuildConfiguration2.

If I choose ICBuildConfiguration as a replacement for the abstract class, I can read the IProject object my code needs. Unfortunately, it does not give me the build directory, I need an instance of ICBuildConfiguration2 to get the directory.
But ICBuildConfiguration2 does not extend ICBuildConfiguration. Is that by intent?
Or is it fine to stay using the abstract class CBuildConfiguration?

Martin

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question on class hierarchy of CBuildConfiguration

15 knots
Am Fr., 17. Juli 2020 um 20:56 Uhr schrieb 15 knots <[hidden email]>:

>
> Hi gurus,
>
> Currently my code takes a CBuildConfiguration object as an argument in its public API.
> CBuildConfiguration is an abstract class and I would like to use an interface instead.
> Looking at the class hierarchy of CBuildConfiguration, I can find it implements interface ICBuildConfiguration and interface ICBuildConfiguration2.
>
> If I choose ICBuildConfiguration as a replacement for the abstract class, I can read the IProject object my code needs. Unfortunately, it does not give me the build directory, I need an instance of ICBuildConfiguration2 to get the directory.
> But ICBuildConfiguration2 does not extend ICBuildConfiguration. Is that by intent?
> Or is it fine to stay using the abstract class CBuildConfiguration?

Well, looking at my latest code , this might be irrelevant. My code
already takes a parameter object. It would be simple to replace its
reference to CBuildConfiguration with references to the IProject and
build dir and force clients to provide the latter instead.

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question on class hierarchy of CBuildConfiguration

Jonah Graham
In reply to this post by 15 knots

I don't know why in some cases extensions to interfaces don't extend the initial interface. I find that irritating and I would simply vote for the *2 to extend the original and then you can use that interface everywhere. Perhaps someone knows why it wasn't done that way initially? 

Although it sounds moot in this case now. But the general sentiment applies and CDT 10.0 is a good opportunity to make that change with minimal disruption. 

Jonah

On Fri., Jul. 17, 2020, 14:57 15 knots, <[hidden email]> wrote:
Hi gurus,

Currently my code takes a CBuildConfiguration object as an argument in its public API.
CBuildConfiguration is an abstract class and I would like to use an interface instead.
Looking at the class hierarchy of CBuildConfiguration, I can find it implements interface ICBuildConfiguration and interface ICBuildConfiguration2.

If I choose ICBuildConfiguration as a replacement for the abstract class, I can read the IProject object my code needs. Unfortunately, it does not give me the build directory, I need an instance of ICBuildConfiguration2 to get the directory.
But ICBuildConfiguration2 does not extend ICBuildConfiguration. Is that by intent?
Or is it fine to stay using the abstract class CBuildConfiguration?

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question on class hierarchy of CBuildConfiguration

Marc-Andre Laperle-3
The normal pattern in Platform is to have “2” to extend the original.

For interfaces that are not expected to be widely implemented I’d suggest collapsing into one on major releases. For this one, I don’t know for sure but it seems likely that people extend CBuildConfiguration anyway so it might be worth doing that clean-up.

Marc-André

On Jul 17, 2020, at 6:27 PM, Jonah Graham <[hidden email]> wrote:


I don't know why in some cases extensions to interfaces don't extend the initial interface. I find that irritating and I would simply vote for the *2 to extend the original and then you can use that interface everywhere. Perhaps someone knows why it wasn't done that way initially? 

Although it sounds moot in this case now. But the general sentiment applies and CDT 10.0 is a good opportunity to make that change with minimal disruption. 

Jonah

On Fri., Jul. 17, 2020, 14:57 15 knots, <[hidden email]> wrote:
Hi gurus,

Currently my code takes a CBuildConfiguration object as an argument in its public API.
CBuildConfiguration is an abstract class and I would like to use an interface instead.
Looking at the class hierarchy of CBuildConfiguration, I can find it implements interface ICBuildConfiguration and interface ICBuildConfiguration2.

If I choose ICBuildConfiguration as a replacement for the abstract class, I can read the IProject object my code needs. Unfortunately, it does not give me the build directory, I need an instance of ICBuildConfiguration2 to get the directory.
But ICBuildConfiguration2 does not extend ICBuildConfiguration. Is that by intent?
Or is it fine to stay using the abstract class CBuildConfiguration?

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question on class hierarchy of CBuildConfiguration

Jonah Graham

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 17 Jul 2020 at 21:37, Marc-Andre Laperle <[hidden email]> wrote:
The normal pattern in Platform is to have “2” to extend the original. 

I agree - the platform explicitly says that it should extend the original - unfortunately in this case it does not.
 

For interfaces that are not expected to be widely implemented I’d suggest collapsing into one on major releases. For this one, I don’t know for sure but it seems likely that people extend CBuildConfiguration anyway so it might be worth doing that clean-up.

+1 - if someone has the time. ICBuildConfiguration2 is a fairly new interface so can be collapsed now.
 

Marc-André

On Jul 17, 2020, at 6:27 PM, Jonah Graham <[hidden email]> wrote:


I don't know why in some cases extensions to interfaces don't extend the initial interface. I find that irritating and I would simply vote for the *2 to extend the original and then you can use that interface everywhere. Perhaps someone knows why it wasn't done that way initially? 

Although it sounds moot in this case now. But the general sentiment applies and CDT 10.0 is a good opportunity to make that change with minimal disruption. 

Jonah

On Fri., Jul. 17, 2020, 14:57 15 knots, <[hidden email]> wrote:
Hi gurus,

Currently my code takes a CBuildConfiguration object as an argument in its public API.
CBuildConfiguration is an abstract class and I would like to use an interface instead.
Looking at the class hierarchy of CBuildConfiguration, I can find it implements interface ICBuildConfiguration and interface ICBuildConfiguration2.

If I choose ICBuildConfiguration as a replacement for the abstract class, I can read the IProject object my code needs. Unfortunately, it does not give me the build directory, I need an instance of ICBuildConfiguration2 to get the directory.
But ICBuildConfiguration2 does not extend ICBuildConfiguration. Is that by intent?
Or is it fine to stay using the abstract class CBuildConfiguration?

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question on class hierarchy of CBuildConfiguration

Marc-Andre Laperle-3
See
https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/166471

Cheers,
Marc-André

On Jul 17, 2020, at 9:42 PM, Jonah Graham <[hidden email]> wrote:


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 17 Jul 2020 at 21:37, Marc-Andre Laperle <[hidden email]> wrote:
The normal pattern in Platform is to have “2” to extend the original. 

I agree - the platform explicitly says that it should extend the original - unfortunately in this case it does not.
 

For interfaces that are not expected to be widely implemented I’d suggest collapsing into one on major releases. For this one, I don’t know for sure but it seems likely that people extend CBuildConfiguration anyway so it might be worth doing that clean-up.

+1 - if someone has the time. ICBuildConfiguration2 is a fairly new interface so can be collapsed now.
 

Marc-André

On Jul 17, 2020, at 6:27 PM, Jonah Graham <[hidden email]> wrote:


I don't know why in some cases extensions to interfaces don't extend the initial interface. I find that irritating and I would simply vote for the *2 to extend the original and then you can use that interface everywhere. Perhaps someone knows why it wasn't done that way initially? 

Although it sounds moot in this case now. But the general sentiment applies and CDT 10.0 is a good opportunity to make that change with minimal disruption. 

Jonah

On Fri., Jul. 17, 2020, 14:57 15 knots, <[hidden email]> wrote:
Hi gurus,

Currently my code takes a CBuildConfiguration object as an argument in its public API.
CBuildConfiguration is an abstract class and I would like to use an interface instead.
Looking at the class hierarchy of CBuildConfiguration, I can find it implements interface ICBuildConfiguration and interface ICBuildConfiguration2.

If I choose ICBuildConfiguration as a replacement for the abstract class, I can read the IProject object my code needs. Unfortunately, it does not give me the build directory, I need an instance of ICBuildConfiguration2 to get the directory. 
But ICBuildConfiguration2 does not extend ICBuildConfiguration. Is that by intent?
Or is it fine to stay using the abstract class CBuildConfiguration?

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev