Re: Library settings, best practices?

[Vladimirs Nordholm via Digitalmars-d-learn]

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 :)

Re: Library settings, best practices?

[Adam D. Ruppe via Digitalmars-d-learn]

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.

Library settings, best practices?

[Vladimirs Nordholm via Digitalmars-d-learn]

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