Problem statement from FLY-87 in Jira Issue Tracker
Code such as the following example from WidgetFigure is bad:
//Both TimerWidgetElement and MathWidgetElement
//are subclasses of WidgetModel.
if (model instanceof MathWidgetElement) {
widgetType = "Math";
} else if (model instanceof TimerWidgetElement) {
widgetType = "Timer";
} else if (model instanceof WidgetModel) {
widgetType = ((WidgetModel) model).getWidget().toString();
}
The task is to clean up garbage such as this and remove it from the bowels of the codebase. It would be really nice if TimerWidgetElement, MathWidgetElement and <insert non-visual widget here>Element where all subclasses of some abstract WidgetElement class or something of that flavor. The ultimate goal here is to ba able to write just one line of code:
if (model instanceof WidgetModel) widgetType = ((WidgetModel) model).getWidgetDescription().getName();
where the name field of the widget's descriptor is actually just the type of widget (Button, or Math etc...). Maybe that's asking too much though.
Tracking Down our Predecessor's Reasoning
It seems that the widget associated with the MathWidgetElement and TimerWidgetElement are not being set, thus leading to null-pointer exceptions. The MathWidgetElement and TimerWidgetElement instances are being produced in the LinkageGraphEditorPaletteFactory (org.eclipse.gef.palette.CombinedTemplateCreationEntry). Further tracking on the way.
Comments (2)
Nov 01, 2005
whoknows says:
that's some pretty vile, nonextensible, nonoo, and dangerous code. every time i ...that's some pretty vile, non-extensible, non-oo, and dangerous code. every time i forget why i don't program with the class, i come across an example like this and remember
just two notes for now:
1/ if they're all models, why are they called 'elements'?
2/ do they really have to subclass a model supertype? couldn't they just implement a model interface?
Nov 01, 2005
Justin R Eylander says:
I just traced back the inheritance heirarchy and found that it terminates with a...I just traced back the inheritance heirarchy and found that it terminates with an abstract class (Model) that implements IPropertySource & Serializable. hmmm... I'm not quite sure what's going on with this yet, but it looks like we can probably pull a meaningful interface out of this. Why Model isn't called AbstractModel implementing a meaningful interface, Model, already is unclear.