* Paul LeoNerd Evans <leon...@leonerd.org.uk> [2013-05-27 01:35]: > On Sat, 25 May 2013 08:52:30 +0200 > Aristotle Pagaltzis <pagalt...@gmx.de> wrote: > > > That’s just what futures are for, I think? As in, they abstract the > > sync/async control flow out of the code. And you’re just putting that > > on top of one common HTTP client API pattern. It seems like discovery > > rather than invention to me. > > Oh sure - I didn't mean to suggest I'd invented the entire concept of > using futures as control flow :) Simply, this particular arrangement > of methods/API details, for solving this particular HTTP problem.
I mean even the method and signature you chose, aside from returning a future, is already a common pattern… then again, in the traditional form that does not involve futures, its value feels more limited, more like a convenience. Involving futures somehow makes it feel more like a protocol than a pattern. In some sense what you’ve done feels trivial and other senses it feels significant, I just can’t quite put my finger on the particulars… > > Naming-wise I’d emphasise futures rather than IO::Async, natch. > > Oh indeedy. Does anything come to mind, though? Tricky, it seemed, because what are we naming and why? After sitting on this for a long time it finally occurred to me the approach that would make sense here would be to make this a role, which requires a `request` method and documents the expected interface. Your webservice wrapper module would take objects that do this role. The naming seems fairly easy then – HTTP::Client::Future perhaps? Maybe HTTP::Client::Role::Future if you want to be perfectly clear? (Actually on first read I thought you were asking about naming advice for your webservice wrapper module. On re-read now it’s not clear to me whether that was a hasty inference and you were already talking about an futures-based abstract API module… but it seems implausible that you’d be asking for naming advice for that? Though I dunno, maybe a case of programmer’s block? Anyway.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
