Virtual methods in KLineEdit

[Christian Schaarschmidt]

Hi,

I have recently commited a change to trunk/.../KLineEdit (bug 137430) and 
after that I had a discussion with Simon concerning virtual methods. Since we 
could not agree upon a solution it would be nice to get some other 
opinions...

Problem: Allow subclasses of KLineEdit to extend context menu
The patch solves the issue by moving the code to createStandardContextMenu(), 
remains the question: should KLineEdit be used as base for a hierarchy? How 
comfortable should it be?
 
Solution A: make createStandardContextMenu() virtual
Pros:
+ straight forward, easy to impliment and understand: overload 
createStandardContextMenu(), call parent:: createStandardContextMenu() and 
add what you want. 
+ supports class hierarchy, all sub-sub-sub-classes extend the menu the same 
way, by overloading createStandardContextMenu() 
Cons:
- perfomance, virtual is more expensive
- QT incompatibility, in QT it is not virtual, you have to overwrite 
contextMenuEvent() to extend the menu (works only for one subclass not for a 
hierarchy, since sub-sub-class has no access to extended menu)

Solution B: createStandardContextMenu() is NOT virtual
Pros:
+ performance
+ QT compatible
Cons:
- if you want to keep the functionality from KLineEdit in sub you have to 
duplicate code from contextMenuEvent() in sub-class and extend menu there
- if you want to support hierarchy  you can either make it virtual or you have 
to overload createStandardContextMenu() to provide subclass access to the new 
extensions AND contextMenuEvent() to make sure the correct version of  
createStandardContextMenu() is called. And again, you have to make sure your  
contextMenuEvent() does the same thing as in parent.

Christian

PS: please CC me, I am not on kde-core-devel