Framework design, initialization and framework usage

[Robert M. Münch]

On 2019-05-06 17:04:47 +0000, Adam D. Ruppe said:

> I'd make that thing's constructor private, and then offer a helper 
> template function that actually creates it and the user passes a type.

Any reason why makeing things private? The struct is more like an 
application state to avoid globals. And I expect that the struct 
members are needed in many places.

> ---
> // inside your library
> struct myFramework {
>     private MyFramework app;
>     private this(MyFramework app) {
>        this.app = app;
>     }
> }
> 
> myFramework initializeMyFramework(FrameworkClass)() 
> if(is(FrameworkClass : myFrameworkApp))
> {
>      return myFramework(new FrameworkClass());
> }
> ---
> 
> Then the user's code would look something like this:
> 
> ---
> import my_framework;
> class myAppCode : myFrameworkApp {
>      // implementations....
> }
> 
> void main() {
>     auto thing = initializeMyFramework!myAppCode;
>     // if you have other stuff to do with thing, you can here.
> }
> ---

What I want to avoid is that explicit init line in main(). So, the user 
should derive whatever make sense for the app, but main() is never 
touched by the user. main() should initialize the user's app code 
"automatically" and be part of the framework.

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