super constructors: I can't take it anymore!

Serg Kovrov 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 
classname.

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 mailing list