3 ms·
Yeah, I generally feel the same way. For fairly simple use, scope is more consistent (all scopes / closures are identical), but func is a bit more flexible if
by Groxx 9y ago
Yeah, I generally feel the same way. For fairly simple use, scope is more consistent (all scopes / closures are identical), but func is a bit more flexible if you're willing to pay with simple boilerplate.
I mean, you can convert them into each other. Scoped can do something like this (go+python blended code 'cuz lazy):
func f(){
deferred := []
defer func() { for d in deferred.reverse(): d() }() // plus error handling
if x.something() {
deferred.push(func(){ cleanup() });
}
// same as func scope
}
but that's a bit more ridiculous / error-prone (though a helper func is obviously possible) than the equivalent IIFE for func -> scope. More explicit, I suppose, but bleh.
- pcwalton 9y agoIt's more explicit, which is a good thing, as it makes the intent clear. This matters if, for example, the function is later refactored to inline into a caller.
- Groxx 9y agoIt also allows more flexibility (do you execute them in the order they were enqueued, or in reverse?), more room for errors, confusion between different patterns / lack of consistency across different codebases, etc. Explicit-all-the-things isn't an unambiguous Good Thing™. If it were, we wouldn't even be discussing this - it's an abstraction, which is less explicit than e.g. building defer out of a list and using GOTO.