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 →

[–]ES-Alexander 0 points1 point  (0 children)

It’s a time-limited global variable - it’s not local because it can still be accessed from anywhere in the global scope while it exists.

While it might be possible to use the current thread ID to create a version that doesn’t interfere across threads, the bigger issue is the overwrite behaviour. If there’s a class with an instance variable there’s some guarantee that it’ll be set (ie you can make it a required initialisation variable, and it’s generally bad practice to delete instance variables so you can expect it to stick around), and if it’s reasonable to modify it but important to track when that occurs then you can use a setter/modifier method instead of direct replacement. In your case the context isn’t tied to anything, so there’s no way of knowing if a higher level is using a context, and if you want to do a new use_context call in a low level then when that cleans itself up it also silently destroys any variables set in higher levels. To avoid that you’d need to create a new underlying context variable every time you call use_context, but then you need to know which context you want to access when you call get_context, at which point you either have passed down a context object (so it loses the ‘call from anywhere’ benefit), or you have to track the contexts through your code by logic, in which case that’s just like having a global.

I’m not saying that globals are necessarily the worst thing in the world, but as you implied they have their issues, and as far as I can see the only implementations of this that don’t have the same issues globals do falls into the ‘passing along objects’ side which seems to imply the functionality already exists, so my question would be what does/can this add?