On Sun, 9 Nov 2003 08:11:26 +0900 James Britt <jamesUNDERBARb / seemyemail.com> wrote: > Ryan Pavlik wrote: > <snip /> > > > This shows that a problem occurred in the code---we don't have > > something that's a row---but it doesn't show you where the _actual_ > > error occured---when someone passed you an Object instead of a Row. > > Isn't the error that the object did not know how to respond to 'rowsize'? The error is that somewhere I inserted an Object when I should have inserted a Row. Checking this at the point of insertion is a simple and elegant way to immediately flag this sort of problem. The fact it doesn't respond to rowsize is only a symptom. Which leads us to... > > The ST module allows you to catch the culprit immediately. > > If I understand the ST module, it doesn't help that an object simply > responds to all the required messages, but rather it must only have > the right pedigree. Right. > Even though having the right pedigree is no guarantee that the > object was not (perhaps pathologically) munged at some point, with > critical methods removed/altered. As in the previous post, this is possible, but there is no incentive to do so. If you want to break your own code, there are quicker and easier ways. > Or does the ST module query an Object with a list of responds_to? > messages? It doesn't, even though I considered something like that, simply because I realized it was the wrong thing to do. "Does it respond to this?" isn't the right question to ask (because it doesn't give you enough inforamtion). "Is this the thing I want?" tells you everything. Of course, if there was a standard conversion mechanism, the ST module could work in conjunction with it to try and provide you with the type you wanted where possible... ConversionTable.add(Float, String) { |f| f.to_s } : def foo(s) expect s, String : end foo 4.2 # => foo "4.2" Hmm, maybe I should release that conversion mechanism after all, and add this... -- Ryan Pavlik <rpav / mephle.com> "You're about a thousand miles of *wrong*." - 8BT