Re: Late binding

Mark Baker wrote,
> The Web is really late bound, because you don't know what you're
> dealing with until after you've invoked GET (most commonly - there
> are other ways).  For example, if I gave you any URI, you wouldn't
> know what it identified until you entered it into your browser.

Hmm ... interesting, that's not quite the way I'd have characterized the 
late/early distinction.

Your contrast seems to be analogous to the difference between,

  class HTTPServer
  {
    public Object GET(); // Late
  }

and,

  class HTTPServer
  {
    public SomeSpecificType GET(); // Early
  }

whereas the traditional OO constrast is between,

  class HTTPServer
  {
    public Irrelevant GET(); // Late
  }

and,

  class HTTPServer
  {
    public final Irrelevant GET(); // Early
  }

ie. you're contrasting early/late binding of result types, whereas the 
traditional constrast is early/late binding of receiver types (hence 
the common usage, "deferring implementation to a subclass").

FWIW, I think RFC 2616 only gets us the traditional contrast, because it 
does specify a particular result type: an entity. Any additional 
subtyping of entities is beyond the scope of the RFC 2616 
(Content-Type: notwithstanding) and only kicks in when additional 
application semantics are layered on top. I say "Content-Type 
notwithstanding, because, at least as far as RFC 2616 is concerned, an 
entity is a concrete type and the Content-Type is merely an annotation 
rather than being an essential characteristic.

I wonder if this different understanding of early/late has any bearing 
on your insistence that HTTP satisfies the "no a priori knowledge" 
constraint. I've always found that baffling, because there clearly is a 
priori knowledge if we understand early/late in the traditional way: we 
know up front that the result of a GET will be an entity (even if we 
don't know the details of how it's produced).

Cheers,


Miles

Received on Wednesday, 26 June 2002 05:06:35 UTC