[kc5tja]

Goodness, I'm confused. I'm going to need a lot of time to digest this. That said, much discussion about ideal way of writing Gophercloud happened on the #go-nuts IRC channel, and nobody objected to what I have now as being unidiomatic. You're the first!

Deeply nested closures are definitely a problem, but I usually solve that by factoring closures out into top-level functions of their own.

That said, one of Gophercloud's goals is to be as idiomatic as possible. Are you available on #go-nuts if I have questions? I'd like to play with this technique some more and get a feel for it before applying it to (and risk breaking) gophercloud's existing API.

[kc5tja]

Oh, I'm thick! I see what's happening now!

The problem is it doesn't produce any gain in clarity for the purposes I'm using it for. I think for the acceptance tests, it's use is fine.

I can see if it were part of the public API, there's an argument that an interface could be used, but even there, I'm not sure it'd aid readability.

Semantically, however, they're of course identical.

[zemo]

yeah, to be honest, it may have been eggregious of me to call how I did it idiomatic. There's a lot we just don't have idioms for. Anyway, callback chains tend to be uncommon; that's just one way to avoid it. There's a handful of ways you could write this. Generally if you can expose functionality through methods, things tend to work out better in the end since you can transition into interfaces more readily. I'm jordanorelli in #go-nuts.