On 14 August 2011 04:27, DreamTangerine <[email protected]> wrote: > OK, I see your point of view and maybe you are right with > List/Table/Tree views (I need to think more about it), but in the case > of text components, here are my points : > > * Three classes with the word "Text" that are also "Component", seem > like share a lot of functionality and need a common class.
I agree. :) I am not saying that the TextXXX Components do not have shared functionality that could be refactored into a base class. In fact that may turn out be the most effective or preferable way of achieving at least part of Roger's idea, but I think some investigation needs to be done first to weigh up the pros and cons. Things might become more complicated due to the Components functionality being split between the Component (and superclasses) and its Skin (and superclasses), and the fact that Skins can be swapped out in any Pivot implementation. In fact it might be the case that any common functionality would exist in the skin class hierarchy rather than the Component class hierarchy. Of course skins are just classes too, so could have shared functionality extracted into a superclass, but I with the current class hierarchy that might be disruptive. Again, it is just something that needs investigation and consideration. This is actually similar to something that I have been meaning to investigate and discuss for a while, but I won't do into detail now so as not to take the discussion off topic. I didn't make this clear in my earlier email, but if a common base class was introduced for these TextXXX Components, the classes would also most likely explicitly implement the proposed interface, so how the interface functionality was achieved becomes (rightfully) irrelevant to the consumer of these classes. Chris
