Well, here’s what I plan to do WRT adding a floating-point renderer to CDT:
·
Leave the Traditional Renderer untouched/as-is.
·
Add the Floating-point Renderer and re-factor to use existing Traditional Renderer classes common between the renderers.
·
If other renderers are added in the future, we can refactor common classes into their own plug-in at that time.
Does this seem reasonable?
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of St. Laurent, Andre
Sent: Monday, October 10, 2011 6:48 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Is anyone extending org.eclipse.cdt.debug.ui.memory.traditional?
Due to customer dependencies on the Traditional Renderer API, I will probably not be able to re-factor that project. Rather, I’ll create [new] common and floating-point projects. And, in that case, it’ll be
CDT 9.0.
Will this require CDT to be 9.0?
From:
cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of St. Laurent, Andre
Sent: Friday, October 07, 2011 12:51 PM
To: CDT General developers list.
Subject: [cdt-dev] Is anyone extending org.eclipse.cdt.debug.ui.memory.traditional?
Hi,
Per my earlier message to the mailing list, I will be adding a floating-point renderer to CDT (via an established committer). As part of this work, I want to do some refactoring, which will include creating a new project (for example,
org.eclipse.cdt.debug.ui.memory.renderers), changing the package, class name changes and other things of that ilk . Before I can do this, however, I need to know if anyone in the community extends any of the classes in
org.eclipse.cdt.debug.ui.memory.traditional. If not, I’m free to refactor things as needed. If there are users who extend the Traditional; Renderer classes, I’ll have to confine my refactoring to the
.traditional project and limit API changes.
Please let me know if you extend any Traditional Renderer classes.
Thanks, André St. Laurent, Wind River Systems, Inc.