Re: Late binding

Hi Miles,

On Wed, Jun 26, 2002 at 10:06:04AM +0100, Miles Sabin wrote:
> 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
>   }

That wasn't my intent.  More below ...

> whereas the traditional OO constrast is between,
> 
>   class HTTPServer
>   {
>     public Irrelevant GET(); // Late
>   }
> 
> and,
> 
>   class HTTPServer
>   {
>     public final Irrelevant GET(); // Early
>   }

IMO, the traditional component-versus-object contrast is;

class WWW-Service
{
  public Something GET();
  ...
}

versus

class My-Stock-Quote-Web-Service
{
  public Something GetStockQuote();
  ...
}

The "type" here is at the class/interface level, not the method/response
level.  So in the former case, a client discovers that the thing is a
stock quote *after* invoking GET, whereas in the latter case, the client
needs to know that it's a stock quote *before* invoking GetStockQuote().

> 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).

What I meant by the "no a priori knowledge" constraint is that HTTP
doesn't require me to know that something is a stock quote in order to
retrieve it (or change it, or hand it some data, etc..).

Does that help explain my previous ramblings? 8-)

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 26 June 2002 07:51:38 UTC