On 9/20/06, Robert Klemme <shortcutter / googlemail.com> wrote: > Leslie Viljoen wrote: > > On 9/20/06, Joel VanderWerf <vjoel / path.berkeley.edu> wrote: > >> Austin Ziegler wrote: > >> > On 9/20/06, Ola Bini <ola.bini / ki.se> wrote: > >> >> The problem with "just use it", is that you will have no control over > >> >> error handling in this case. > >> > > >> > This is demonstrably untrue. Duck typing is not about validation. It's > >> > about trusting your callers to do the right thing -- and then doing > >> > the right thing when they don't. > >> > >> To extend Austin's point a little: In ruby, it really has to be this > >> way. What if an object responds to a message by way of method_missing? > >> There's no easy way to validate that. > > > > Of course the whole scheme really relies on the library writer to > > provide very good documentation - they have to (re)discover and > > document every method call they perform on every object passed to > > them. Unless they fall back to the old ways and say "this method > > expects a string, and all that that implies". Which doesn't help the > > user of the library much because say they want to pass in something > > else that works a little like a string, but does not exhaustively > > support every method the String class supports? They have to read the > > library source and discover and document every method call on the > > object... > > Maybe it has to be a String - maybe not. If not, you can use a probe > > class Probe > def method_missing(*a,&b) > p [self, *a] > end > end Ah thank-you, that's great. But it would not work unless every execution path within the method receiving the object was executed: class Probe def method_missing(*a,&b) p [self, *a] end end def testProbe(probe) if probe>5 puts probe.destroy else puts probe.accept end end p = Probe.new testProbe(p) --------------------- lesliev@derik:~$ ./testProbes.rb [#<Probe:0xb7cbaa70>, :>, 5] [#<Probe:0xb7cbaa70>, :accept] nil ...so is there some magic that could overcome that limitation?