--0015175cdeb84f43e3046bb73bc8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I should add that further examination reveals that people who make proxy objects (Drb, Rails Association Proxy) expect that their respond_to? will work correctly. If implementations were allowed to do internal checks only, proxies would need to explicitly define all coercion methods, something they do not currently do. -- Yehuda On Sat, Jun 6, 2009 at 5:12 PM, Yehuda Katz <wycats / gmail.com> wrote: > Matz, > > I've been working on adding some specs to RubySpec related to the > ducktyping interface. I have observed the following behavior and want to > know whether or not it's intentional. Let's use the #to_s coercion as an > example: > 1. If the object has a method #to_s, it's called. > 2. If #to_s returns something that is not a String, a TypeError is raised. > > In MRI, the mechanism for determining if an object has a method #to_s is to > call respond_to?. This means that even if the method does not exist, #to_s > will get called, and fall through to #method_missing, if the #respond_to > method returns true for :to_s. As a result, when using MRI, it is possible > to implement the duck-typing interface without defining #to_s, but instead > defining a combination of #respond_to? and #method_missing that returns a > String. > > Is this intentional? Would it be ok for an alternative implementation to > look up the #to_s method using an internal check instead of calling the > user-defined #respond_to?, as MRI does? > > In other words, is the only "correct" way to enlist in Ruby coercion to > define to_s explicitly, or is another correct way to define respond_to? and > method_missing to return an appropriate response? > > -- > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325 > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --0015175cdeb84f43e3046bb73bc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should add that further examination reveals that people who make proxy objects (Drb, Rails Association Proxy) expect that their respond_to? will work correctly. If implementations were allowed to do internal checks only, proxies would need to explicitly define all coercion methods, something they do not currently do.<div> <br></div><div>-- Yehudabr><br><div class="gmail_quote">On Sat, Jun 6, 2009 at 5:12 PM, Yehuda Katz <span dir="ltr"><wycats / gmail.com></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div>Matz,</div><div><br></div>I've been working on adding some specs to RubySpec related to the ducktyping interface. I have observed the following behavior and want to know whether or not it's intentional. Let'sse the #to_s coercion as an example:<div> <br></div><div>1. If the object has a method #to_s, it's called.</div><div>2. If #to_s returns something that is not a String, a TypeError is raised./div><div><br></div><div>In MRI, the mechanism for determining if anbject has a method #to_s is to call respond_to?. This means that even if the method does not exist, #to_s will get called, and fall through to #method_missing, if the #respond_to method returns true for :to_s. As a result, when using MRI, it is possible to implement the duck-typing interface without defining #to_s, but instead defining a combination of #respond_to? and #method_missing that returns a String.</div> <div><br></div><div>Is this intentional? Would it be ok for an alternative implementation to look up the #to_s method using an internal check instead of calling the user-defined #respond_to?, as MRI does?/div><div><br> </div> <div>In other words, is the only "correct" way to enlist in Ruby coercion to define to_s explicitly, or is another correct way to define respond_to? and method_missing to return an appropriate response?</div><div> <br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br> </div> </blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br> </div> --0015175cdeb84f43e3046bb73bc8--