implicit-context v0.0.1

[drug007]

On 29.09.2023 18:30, Guillaume Piolat wrote:
> On Friday, 29 September 2023 at 15:00:33 UTC, Imperatorn wrote:
>>
>> I think for this to be truly valuable, it would require being part of 
>> the language.
> 
> Only if proven on DUB.
> 
>> I admit I haven't really thought about implicit parameters before your 
>> post, so I might be missing something.
> 
> Think of it like envvars for threads. When you launch a process, the 
> launcher knows to copy the environment variables. With scattered TLS 
> variables, no new thread can get a copy of all the "context" it may 
> have. But with a centralized place for context, you will be able to do 
> that (not implemented yet), which kinda improves encapsulation.
> 
> 
> **Example 1: Context variables are scoped**
> 
>    In a UI library, every new widget typically get a "UI context" (that, 
> or factory functions only) polluting all the constructors there is.
> 
> Solution: Just append "uiContext" variable in the context => less 
> parameters.
> 
> But it could be a TLS variable, right? Yes indeed, but then you may want 
> to scope that, to remove the global from being accessed outside a 
> particular scope. Globals can be accessed at any time, which doesn't 
> improve a public API.
> 
> 
> **Example 2**
> 
> When my "gfm" package was forked to "gfm7", the first thing that was 
> done is:
> - remove all the _gl members that would only there to confirm a 
> particular shared library was used => it is part of the context
> - and removed all logger interface passing => also ugly and kinda never 
> changes
> 
> 

But later I understand that the removing of gl has also disadvantages. 
In general implicit context is really the great idea