Framework design, initialization and framework usage

Robert M. Münch robert.muench at saphirion.com
Tue May 7 09:58:48 UTC 2019


On 2019-05-06 18:21:27 +0000, Adam D. Ruppe said:

> Just the constructor. It is so they don't try to skip a step calling 
> the constructor themselves. But, of course, it doesn't have to be 
> private.

Ok, that makes sense.

>> What I want to avoid is that explicit init line in main().
> 
> I did things that way with cgi.d and regretted it later (and the vibe.d 
> authors, as I understand it, also did something like you are describing 
> and regretted it later too).
> 
> It is actually really useful to have the user write their own main. It 
> makes the flow clear with a familiar starting point. Even if all it 
> does is actually call a framework function to do all the real work, 
> having that main gives people unfamiliar with your framework an idea of 
> where to start in understanding this code.

Yes, I agree and think that makes a lot of sense in many cases, but I 
need to elaborate on my framework context a bit, why I would like avoid 
it: The application framework contains a message event loop (let's use 
the Windows case) and set's up all the necessary Windows environment 
and boilerplate code.

While a default window etc. is created, the user app should be called 
with different init functions. Like: init_1 when the program execution 
started, init_2 when the debug console is available, init_3 when the 
windows classes are registered, init_4 when the window is shown.

During one of the init functions, the user app would register for the 
events it is interested in. And the app framework would do the message 
dispatching.

So, in my case there would be a clear sequence how things are started 
and where the app fits in.

> And besides, you are going to need some kind of user-customized code to 
> select which class they want to use. You could create a global variable 
> with some predefined name... but how will it know which class to put in 
> there? Is it going to be static?
> 
> extern(C) __gshared MyFramework _framework = new MyApp;
> 
> like you could do that... but it will be a weird error if the user does 
> it wrong, or does it twice, or whatever. Or if their MyApp constructor 
> can't be run at compile time, that is also an error here.

My idea is more, that the user code somehow needs a simple to follow 
"registration" step to tell the framework: This is the main object to 
use to call the init functions, etc. I think a static constructor or so 
can do the job.

For the "to be registered" type I see two options:

1. use a base class that provides virtual functions for a small set of 
application functions that need to be implemented.

2. use an interface from which the user app class is derived. But can I 
use an interface as a type in my framework? I don't think so. So, how 
to get the user's app object type into my framwork, so that the 
framework can call the appropriate functions.


-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



More information about the Digitalmars-d-learn mailing list