> `ctx.Value` is an `any -> any` kv store that does not come with any documentation, type checking for which key and value should be available
The docs https://pkg.go.dev/context#Context suggest a way to make it type-safe (use an unexported key type and provide getter/setter). Seems fine to me.
> What if you just use a custom struct with all the fields you may need to be defined inside?
Loom is useful as an underlying mechanism for an IO monad. What I mean is that Java as language still lacks important features so they have to deliver half-baked things like that "structured concurrency". From my point of view these new abstractions are evil - the better ones were out there for a while.
Well yeah, it's closing over a variable that is not actually part of the properties of the function objects that are returned.
Object.freeze makes the shape (and therefore the properties) of an object immutable. It makes no guarantees about variables being closed over by a function. Those are different semantics altogether.
That feels similar to my earlier example of properties of nested objects not being affected by Object.freeze. And in this case, being able to freeze closed variables would in a sense mean exposing those variables. Which is not how closed variables work in JS (in fact it's one of the best ways to mimic "private properties" - except they're not really properties).
There are two types of immutability in JS: one is rebinding a variable (forbidden by the const keyword) and the other is modifying an object (forbidden by freeze)
In javascript these are similar as environment closures behave sort of similar to prototype chains.
One way to work around this is to serialize the argument to harden back to source, eval() it and then harden, which will prevent the captures from working.
The book Radical Markets proposes the following tax (to replace most other taxes), quote:
Every citizen and especially corporation would self-assess the value of assets they possess, pay a roughly 7% tax on these values and be required to sell the assets to anyone willing to purchase them at this self-assessed price.
This is a horrible proposal. Do I have to put a price on my family's home? And if I price it just right, be forced to sell to some speculator who wants it just because he has more money than I do?
Another way to think about it is, that you adjust the price continuously. If a speculator offers you money, you are in the position to take the offer or raise your own valuation and pay the increased tax. At some point a sensible person would be like: screw this, I am moving out of the city because the offers are so high, resulting in very high taxes, which is the intended effect.
Maybe can work for some types of assets one doesn't use, like parked domains
In your example, you could also say "I have to put a price on our cat, and...?" Or your glasses, or your jeans and underpants. But the proposal probably didn't have such things in mind
First, under this system, long-term speculation is not really viable, due to the high tax. So the buyer must have some reason for paying higher than the price you set, which you don't see, i.e. you under-utilize the asset. Google/Facebook ads work this way - every slot is always up for auction. Also similar dynamics in partnership agreement's "shotgun clauses", etc.
Second, you can always factor in your sentimentality into your price, then the buyer will buy your neighbor's house instead. But you have to pay for it in the form of a higher tax. This is like a penalty for obstructing economic efficiency.
Third, this system pretty much does away with the strict idea of private property, into what they call "partial common ownership". It's basically a way to have shared ownership (as in communism) without the central planning, i.e. in a way that might actually work. (In fact, it quite reduces the role of government.)
I'm not advocating for this system, but I think it's fun to think about.
This is so obviously what needs to happen, it's really surprising it's not a feature in all major languages by now. I bet in 10 years time, giving dependencies complete control would seem crazy.
The docs https://pkg.go.dev/context#Context suggest a way to make it type-safe (use an unexported key type and provide getter/setter). Seems fine to me.
> What if you just use a custom struct with all the fields you may need to be defined inside?
Can't seamlessly cross module boundaries.
reply