On Mon, Oct 31, 2016 at 6:13 PM, Tobias Thierer <tobi...@google.com> wrote:
> On Fri, Oct 28, 2016 at 12:28 PM, Michael McMahon < > michael.x.mcma...@oracle.com> wrote: >> >> 2.) HttpHeaders: I love that there is a type for this abstraction! But: >> >> - >> >> Why is the type an interface rather than a concrete, final class? >> Since this is a pure value type, there doesn’t seem to be much point in >> allowing alternative implementations? >> >> You could conceive of different implementations, with different tradeoffs >> between parsing early or lazily for instance. >> > > What parsing are you referring to? > P.S. In case you were referring to lazy HPACK decompression [RFC 7541 <https://tools.ietf.org/html/rfc7541>]: I'll have to read up the details to understand if and how much work could be done lazily, but I can see the consideration. Such a lazy implementation would need some new (potentially package private) way to be passed the un-processed header data. Note that RFC 7540 section 4.3 <https://tools.ietf.org/html/rfc7540#section-4.3> mandates that at least some minimal header processing must be done eagerly to verify the compression and to maintain the state needed for decompression. For what it's worth, though, to allow other implementations, HttpHeaders need not be an interface; it should be sufficient for just the method Map<String, List<String>> asMap() to be abstract or overridable? Of course, if HttpHeaders were shrunk to only that one method, then an interface would be fine. Tobias
