Hello.

Pre-rant:
---------
I have a library to aid in development for the terminal. This library has to initialize some things before it can be used, and I run some code in `shared static this(){...}`. I believe in the most common case scenario my initializer should be run.

The initializer sets the terminal to allow input and better output performance, but makes the terminal not behave as usual.

I believe that sometimes, not all features (input and output) are wanted. As mentioned, to optimize output, some ANSI commands are called, which messes with ordinary `std.stdio.write(...)`. To get input via my library's functions a new thread is created, and some other things happen, which might not be desired.

Initially, I did have a initalizer function which the user had to call, but I myself often forgot to call the function when making a small program, and got stuck because the library didn't initalize.

Actual question:
----------------
Is there a best practice to enabling specific parts of a library?

Ideally I would prefer to not have them at all, but I myself sometime find it necessary to only use a part of the library.

Also as mentioned, I strongly prefer to not have the user call initializer functions themselves.

More ranting:
-------------
Some thoughts I have (which I'm not sure are the best way to approach this issue with) are:
* only parts of the library compile (like how `static if(...)` and `version (...)` works) depending on what parts should be used.
* put settings in a file in `dub.json/sdl`, or a separate settings file.

As a final note, I do not intend for my library to be like vim, with a million `#ifdef`s. Only the two main parts (input and output) should be available to enable/disable.

These are my thoughts, and any input is highly appreciated. If anyone has had experiences with similar issues before, please share them.

And if the absolute best way is to have user-called (de)initializers, then I guess I have to bite the sour apple ;^)

Best regards,
Vladimirs Nordholm

On Saturday, 8 December 2018 at 16:58:24 UTC, Vladimirs Nordholm wrote:
> Is there a best practice to enabling specific parts of a library?

For my terminal library, I put it all in a struct. Then the user gets to choose how to initialize it, and its destructor gets a chance to cleanup when done. The terminal object also contains its methods so you feel like you are getting something out of it by using them.

I know you prefer not to have the user call initializer functions, but I really do think it is the cleanest way to do it.


Alternatively, you could perhaps have it keep an internal is_initialized flag and lazily call init on your other function calls if it is not already done. Then if the user wants to customize settings, they just call init before calling anything else, and if not they skip the init call and it gets default setup first time they try to use it.

On Saturday, 8 December 2018 at 17:05:50 UTC, Adam D. Ruppe wrote:
> Alternatively, you could perhaps have it keep an internal is_initialized flag and lazily call init on your other function calls if it is not already done. Then if the user wants to customize settings, they just call init before calling anything else, and if not they skip the init call and it gets default setup first time they try to use it.
I have not tried this approach before. This might be what I am looking for. Thanks :)