5 ms·
Different people have different appetites for magic (and different definitions of what magic is). For my first magic trick, I'd like to make something not equa
by mrkeen 2y ago
Different people have different appetites for magic (and different definitions of what magic is).
For my first magic trick, I'd like to make something not equal to itself:
foo("bar") == foo("bar")
> false // Magic!
This is easy enough. You can make foo(..) do different things by giving it an implicit dependency on the state of the world. I'll notate implicit dependencies with [].
foo[world1]("bar") == foo[world2]("bar")
> false // Perfectly reasonable behaviour
Where does this pop up "in the real world"? Devs always hit the "what time is it" problem [1]
assertEquals ( "12:23", foo[time1]("bar") )
> Fail!
If you like magic, there's at least two fixes in Java land. 1: You can use some kind of mocking-framework magic to override what your actual clock does (in a way which is not visible in the non-test source code). 2: You can inject a fake clock service into your bean-wiring-framework so that you can control the clock during testing. Others seem to like these two, but they make me barf.
The way I fix it is to just make the implicit explicit instead, by turning them into parameters.
assertEquals ( "12:23", foo[](time1, "bar") )
> Pass!
Not only is it the simplest (subjectively), the technique works in any language.
I feel like thread-local takes this magic to the next level:
assertEquals ( three(), one() + two() )
is really:
assertEquals ( three[thread m](), one[thread n]() + two[thread o]() )
[1] https://stackoverflow.com/questions/2425721/unit-testing-datetime-now https://stackoverflow.com/questions/2425721/unit-testing-dat...
- geocar 2y ago> Different people have different appetites for magic (and different definitions of what magic is). Magic just means "I don't understand this" And whilst I don't think it's that complicated, I also don't think you really need to understand how TLS works to use it any more than you need to understand auto mechanics to drive a car. It's faster than walking. > I feel like thread-local takes this magic to the next level: > assertEquals ( three(), one() + two() ) > is really: > assertEquals ( three[thread m](), one[thread n]() + two[thread o]() ) So I think it's more like: assertEquals ( thread[o][three](), thread[o][one]() + thread[o][two]() ) versus: assertEquals ( data[three](), data[one]() + data[two]() ) That is to say: - TLS is indexed off of a base address, just like data. - The thread "o" is going to be the same in each expression, so if thread[o] can live in a special-purpose register like %fs then it won't take a general-purpose register. If data can live in a special-purpose register... Perhaps with a better picture you too will consider TLS is basically the same as non-TLS, except it's sometimes faster because, well, special circuitry. If anything accessing via "data" is the weird one because even though it looks like you could just set data=0, you'd find almost everyone does it indirectly via %rip, and a variable "foo" is going to be %rip(-5000) in one place and %rip(-4000) in another, but would always be %fs:-26(0) if it were TLS.
- mrkeen 2y ago> Magic just means "I don't understand this" Does this mean I don't understand that objects can have private mutable variables, or that I don't understand random() or getCurrentTime() ? > The thread "o" is going to be the same in each expression I don't accept the premise that I'll always be on the same thread, and if I did, I wouldn't need thread-local in the first place.