Consider moving utility functions to a snap-util package? #163

afcowie opened this Issue Dec 30, 2012 · 1 comment


None yet
2 participants

afcowie commented Dec 30, 2012

At some point you mentioned that you wouldn't really want an HTTP client library depending on Snap. Bit heavy, of course. However, for the usual case of POSTs of type application/x-www-form-urlencoded (and query string parameters too, should I ever include such a helper), one needs to properly encode things.

The code for urlEncode in Snap.Internal.Parsing is lovely, of course — and performant, too! It's sorta a no-brainer to use that, but to do so of course necessitates importing Snap.Core (urlEncode) which leads to the aforementioned dependency on snap-core.

I could just clone the code out lock-stock-and-barrel but it's a complicated piece of work and I'd hate to have to rip it off (and FastSet, and, and) just for this one function. So at the moment I've put a dependency on snap-core but I was wondering if things like this could be migrated to a snap-util package or so?



gregorycollins commented Jan 14, 2013

We spoke about this off-thread -- my position on this is that small amounts of code duplication is better than library proliferation. For http-streams it's worth reimplementing a bunch of 5-10 line functions in order to escape a dependency on snap-util or snap-core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment