From: Sean O'Dell <sean@...>
Date: 2003-11-20T06:32:00+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata  about attribute types)

On Wednesday 19 November 2003 01:25 pm, Austin Ziegler wrote:
> On Thu, 20 Nov 2003 05:17:10 +0900, Sean O'Dell wrote:
> > On Wednesday 19 November 2003 11:47 am, Weirich, James wrote:
> >> Can you give an example of where someone would NEED to check.
> >
> > Okay, you got it. Here's an example of how this sort of type checking
>
> would
>
> > be useful:
>
> [...]
>
> > He decides to build the full HTTP request as a text file, and pipe the
> > file to the CGI method through my library by opening it with the File
> > object and passing a File object where I was expecting a Socket object.
>
>   irb(main):002:0> require 'socket'
>   => true
>   irb(main):003:0> Socket.ancestors
>   => [Socket, BasicSocket, IO, File::Constants, Enumerable, Object, Kernel]
>   irb(main):004:0> File.ancestors
>   => [File, IO, File::Constants, Enumerable, Object, Kernel]
>   irb(main):005:0> Socket.methods - File.methods
>   => ["pack_sockaddr_in", "do_not_reverse_lookup", "getservbyname",
>   "do_not_reverse_lookup=", "unpack_sockaddr_in", "socketpair",
>   "gethostbyname", "getaddrinfo", "pair", "getnameinfo", "gethostname",
>   "sockaddr_in", "gethostbyaddr"]
>   irb(main):006:0> Socket.instance_methods - File.instance_methods
>   => ["bind", "sysaccept", "recvfrom", "accept", "listen", "connect"]
>
> Aside from the above methods, as long as your HTTP server doesn't depend on
> those items in the place where Bob would send the request (you *have*
> designed
> your code with appropriate separation of concerns, haven't you?), then I
> see no problem.
>
> > The code goes BOOM. The library is trying to make calls to methods that
> > don't exist. Bob sees what methods are being requested, but he has no
> > reference to them. Nowhere does he see "I expected a Socket."
>
> Since Bob is a smart programmer, he'll see in his error log:
>
>   NoMethodError: undefined method `accept' for #<File:3>
>         from ...
>
> Well, this means that his File object doesn't know the method #accept.
> Therefore, he can open the source to your HTTP library and see "oh! this
> guy's
> expecting a Socket and has put accept in the wrong place!" If Bob's a
> really smart programmer, he'd already know that #accept is a Socket method.

Wrong!  There's no mention of the Socket object anywhere!  The only way he 
would know that is by searching the source code of OTHER METHODS that call 
that method, then tracing back to where the object that is passed in was 
created.  Then he can see Socket.new.

Also, don't make the assumption that the developer automatically knows #accept 
belongs to the Socket object.  Your familiarity with Socket is causing you to 
discount the pain a developer feels when this sort of error occurs.  A 
developer may know NOTHING about the Socket object and will not have a CLUE 
about #accept.

> I've found bugs in libraries and bugs in my own code -- with the software
> working *just as it does already*. Your scenario doesn't stand.

Sure it does.

	Sean O'Dell