super constructors: I can't take it anymore!
kovrov at no.spam
Wed Aug 16 05:15:49 PDT 2006
* Oskar Linde:
> Or, you can reconsider your design. One option is to make a register()
> method that only the BaseWindow constructor calls. In you child classes,
> you can overload the register() method anyway you wish.
Yes, I thought about reconsider design to workaround this issue, but I
can't find clean solution yet.
Let me clear my design. Obvious hierarchy - a base class for common
any-window functionality, and subclasses for common window cases (such
top frame, button, reac hedit, etc) which may have more narrow but still
generic, and finally end-user-classes for particular application.
All windows classes must register (once) os class with its window
procedure, and create a os window *when instancing*. That is one thing I
do not want to change. e.g, when I do `new Button("push me")` I have
button object ready for action. no need/worry to init it, it should be
inited in constructor.
Ok, next. I want unique window procedure for each 'generic' window
class. eg BaseWindow FrameWindow, Probably I need to explain more, but
do not want to bloat this message. In few words it is for performance
reasons. And that approach I'd like to keep too.
My original idea was - each of constructors call register() and create()
methods with different parameters - window procedure callback and window
Your idea to overload this methods in each subclass should work, but
IMHO it is bad because of duplicating of code. There is lot of redundant
code in register and create methods I can't avoid. I can write a
wrappers for them and overload those wrappers, then.
But isn't is silly to have such ugly workarounds instead of sane
constructors? It is wery hard to follow such not clean code. To help
others (and myself) to understand why there is done so, I'll need to
comment code, but this still workaround, but not solution.
This is main problem with C (atleast how I see it) - when people looking
at code, they see lot of workarounds and quirks hiding actual domain
logic. I see no way for C-code to avoid redundancy and code bloat. Thats
why I looking forward at D.
More information about the Digitalmars-d-learn