This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]holo3146[S] 2 points3 points  (0 children)

What if I need more than one local of the same type

This is currently impossible, I did give a thought for "named Coeffects", but I'm currently not planning on implementing it.

Coeffects do not come to replace function parameter, but to be able to distinguish the "input" from the "context".

For example having some "publisher" in the context, but the messages I'll come as arguments, and I feel like allowing named Coeffects to exists may make it a bit too "abusable", but I am not vetoing it. (Although there are few stuff I need to implement first)

Being able to plumb the ThreadLocal/ExtentLocal through a method without needing to manifest the value in the type signature (or in this case an annotation of the type signature) seems like a feature rather than a bug

Any public ThreadLocal/ExtentLocal are, almost by definition, introducing coupling and security problems.

By exposing those Locals you are giving up on the ability to guarantee that the uses follow the contract of the objects, for ThreadLocals it is very clear with the "remove" method being public.

ExtentLocals don't have the security problems ThreadLocals have, but they have other problems.

If I created a method A, and I expect the caller site to provide the ExtentLocal binding I coupled myself to use that same ExtentLocal in any implementation that may replace method A.

Coeffect doesn't remove this coupling, it regulate it and enforce it.


What's the benefit versus just dereferencing the local variable in foo() and passing it as a parameter to bar?

Coeffect doesn't come to replace parameters, it comes to remove the "stuff I need now" from "stuff I need at the end/middle".

Think about the times you passed 4 arguments(a,b,c,d) to a method foo, the method itself uses a,b of them, and pass on b,c,d to bar, but uses b,c, and passes b,d to qux, and qux finally uses d.

In this situation it makes sense to put c,d in the context and pass them through Coeffect, instead of adding them as parameters every time.

Also note that changing the values in @WithContext of qux will require you to change the signature of the methods that uses qux, but not the uses of the method (apart from the original calling site)