[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cdt-dev] Theoretical Question
- From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
- Date: Wed, 25 Apr 2012 13:31:28 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: Ac0i+FvuLjJQfXOhQl6Rw3Ff8fc6pAAD/aew
- Thread-topic: [cdt-dev] Theoretical Question
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jason Litton
> Sent: Wednesday, April 25, 2012 11:30 AM
> To: CDT General developers list.
> Subject: [cdt-dev] Theoretical Question
> When I'm writing code extending CDT, I find I have a really
> hard time doing the things I need to do because a lot of
> classes that I'd like to extend have hordes of private
> variables with no getters. That means that an extending class
> doesn't have access to its own information. For example, I'm
> extending the GDB Control classes and, to register my class
> to the DSF service provider, I need to provide a
> GDBControlDMContext, which is contained, totally privately
> and with no access, by the parent class. So I either have to
> hack my way around or I have to change the visibility of the
> variable in the parent class. I'm willing to change the
> variable, or at least put a getter in the parent class, but
> I'm wondering why CDT does things this way? It greatly limits
> the ability to extend vital pieces of the code and just seems
> to make things more complicated than they need to be. Do we
> want to keep everything hidden away where only CDT-layer
> things can have it, or is it acceptable to open
> things up a little where extensions need to happen?
My approach has been to keep things hidden when they are
accessible another way. This keeps the API smaller and allows
to change the implementation details without needing to keep
things around for backwards compatibility.
This does not mean that everything is properly visible for
100% extensibility. If things are missing, please let us know
through bugzilla and we can add them.
In the example you give though, you can get the GDBControlDMContext
using ICommandControlService.getContext() or simply getContext() from
your child class.
I hope this helps.