Hacker News new | ask | show | jobs
by gravypod 2122 days ago
I think golang is in a unique position to make `ThreadLocal`-like communication-by-state a workable solution due to the go-routine process model. You can get the benefits of imitable-ness + type safety of `ThreadLocal`-ness with some simple maneuvering.

This could be accomplished by treating "context" like in-process environment variables. Essentially:

1. My Threadlet Variables are immutable to me.

2. I can create children Threadlets (by default) inherit all of my Threadlet Variables.

3. I can modify the Threadlet Variables of my children Threadlets.

This could look something like this (Java + Golang mashup):

    class User {
        ...
    }

    class UserSingleton implements ThreadletLocal {
         // implements static set() and static get() and reset() or something
    }

    requestMiddleware(request, next) {
        go next(request), Context.with(
           UserSingleton.set(extractUserFrom(request.headers)),
           DeadlineThreadletLocal.within(1 second)
        );
    }


This idea is much more refined and further developed in Laravel's facade APIs. They can bind an object dynamically to a "class" and change that underlying implementation dynamically. The benefit of this approach is you can actively distinguish between: 1. who is using your the User class and 2. who is injecting/receiving a User class statically. This allows you to automatically track your "DI". You could also make some syntactic sugar for this like:

    class UserSettingsController {
       @ProvidedBy(UserSingleton.class)
       Optional<User> user;

       .... some code here who talks to user ....
    }

From a Java perspective I think this should be possible post-Loom.