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
