Conflicts between using respond_to? and extending Ruby

ruby-talk
21

Not to mention different, and sometimes VERY different techniques to
'play' them.

···

On 10/22/07, David A. Black <dblack@rubypal.com> wrote:

I've always thought that the situation with programming languages is a
lot like that with musical instruments: they (languages or
instruments) all do the same thing (implement algorithms or make
music), but there's no denying, in either case, that different ones
have very different properties and provide very different experiences.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

22

case obj
  when Array
    ...

is safer and more accurate. i think it really depends on the use case - i personally use both.

It does indeed depend; they do totally different things.

not entirely - they both allowing pre-testing to see if code is going to work or explode...

I was
describing the differences, specifically in the context of duck typing
(or alternatives to duck typing): respond_to? gives you information
about an object at a given moment, and kind_of? tells you about its
ancestry.

well sortof:

   OpenStruct.new.respond_to?(:foo) #=> false

   OpenStruct.new.foo() #=> nil

as i said, i think it's 100% situational and you really can't make blanket rules.

cheers.

a @ http://codeforpeople.com/

···

On Oct 22, 2007, at 11:26 AM, David A. Black wrote:
--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

23

For instance, playing a brass or woodwind instrument simply requires a
rest every now and then.

I'm not sure what the programming language analog is, maybe memory
management in C or something.

···

On Oct 22, 6:12 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

On 10/22/07, David A. Black <dbl...@rubypal.com> wrote:

> I've always thought that the situation with programming languages is a
> lot like that with musical instruments: they (languages or
> instruments) all do the same thing (implement algorithms or make
> music), but there's no denying, in either case, that different ones
> have very different properties and provide very different experiences.

Not to mention different, and sometimes VERY different techniques to
'play' them.

--
-yossef

24

Trans posted a reply to my article saying that I was being too hard on
is_a?/kind_of? I responded there but thought that I should repeat
what I said here:

Trans said:
    I think you're a little too hard on is_a?/kind_of? though. I don't
think they fit the "chicken" typing character quite as well. Yes, they
aren't 100% in a dynamic language such as Ruby's, however they are
much much more dependable than respond_to? b/c modules and class
intend to represent an encapsulation of behavior. If we ask 'is_a?
Enumerable', we can be pretty sure that we are working with something
that responds to #select or what have you as the way we'd expect.

My reply:
True enough, but I wouldn't say much more dependable. Even within an
implementation hierarchy, the signature and even the meaning of a
method can change. Consider, for example how the details of the each
method vary depending on whether the enumerable is, say, a Hash, vs.
an Array. You're typically expecting certain things to be yielded to
the block by each, and neither kind_of? or respond_to? helps predict
either the arity for the block expected, or what will be yielded.

And the flip side argument against chicken typing with kind_of? is the
false negative problem. There are interesting cases where unrelated
classes implement similar methods or families of methods.

And sometimes the method similarity can be complex, making determining
substitutability difficult. Consider how many classes implement some
form of [], and how many variations of parameters there are affecting
the semantics, even within the same class.

While some of the chicken typing persuasion might look at this as a
mess needing to be cleaned up, duck typers see it as the powerful
flexibility that gives Ruby it's agility when coupled with the right
approach and tools.

···

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

25

Hi --

case obj
when Array
   ...

is safer and more accurate. i think it really depends on the use case - i personally use both.

It does indeed depend; they do totally different things.

not entirely - they both allowing pre-testing to see if code is going to work or explode...

Pre-testing is what you do, not what the method does :slight_smile:

I was
describing the differences, specifically in the context of duck typing
(or alternatives to duck typing): respond_to? gives you information
about an object at a given moment, and kind_of? tells you about its
ancestry.

well sortof:

OpenStruct.new.respond_to?(:foo) #=> false

OpenStruct.new.foo() #=> nil

You're a hard task-master :slight_smile: OK, I'll try again:

respond_to?(:x) gives you information about an object at a given
moment -- namely, whether or not any of the classes or modules
currently in an object's method lookup-path has a method "x" defined
(including the object's singleton class).

kind_of?(m) tells you about an object's ancestry -- namely, whether or
not a class or module called m is among its ancestral classes and
modules.

And yes, I know you can do:

   s = "hi"
   def s.respond_to?(x)
     true
   end

and I think people have sometimes even advocated this for OpenStructs.
But the above is as watertight as I can get :slight_smile:

as i said, i think it's 100% situational and you really can't make blanket rules.

I think we're talking at cross purposes; I wasn't suggesting rules,
blanket or otherwise, just commenting on the difference(s) between
respond_to? and kind_of?

David

···

On Tue, 23 Oct 2007, ara.t.howard wrote:

On Oct 22, 2007, at 11:26 AM, David A. Black wrote:

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
   * Advancing with Rails, Edison, NJ, November 6-9
   * Advancing with Rails, Berlin, Germany, November 19-22
   * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!

26

>
> > I've always thought that the situation with programming languages is a
> > lot like that with musical instruments: they (languages or
> > instruments) all do the same thing (implement algorithms or make
> > music), but there's no denying, in either case, that different ones
> > have very different properties and provide very different experiences.
>
> Not to mention different, and sometimes VERY different techniques to
> 'play' them.
>

For instance, playing a brass or woodwind instrument simply requires a
rest every now and then.

I was thinking more along the lines like you don't play a kettledrum
with a guitar pick, or a guitar with mallets. (At least not usually).

I'm not sure what the programming language analog is, maybe memory
management in C or something.

A better analogy here might be playing a woodwind, where you have to
do your own "breath management" vs. playing a pipe organ, which has a
"breath collector!"

···

On 10/23/07, Yossef Mendelssohn <ymendel@pobox.com> wrote:

On Oct 22, 6:12 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:
> On 10/22/07, David A. Black <dbl...@rubypal.com> wrote:

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

27

Hi --

I've always thought that the situation with programming languages is a
lot like that with musical instruments: they (languages or
instruments) all do the same thing (implement algorithms or make
music), but there's no denying, in either case, that different ones
have very different properties and provide very different experiences.

Not to mention different, and sometimes VERY different techniques to
'play' them.

For instance, playing a brass or woodwind instrument simply requires a
rest every now and then.

I was thinking more along the lines like you don't play a kettledrum
with a guitar pick, or a guitar with mallets. (At least not usually).

I think I took the bit about hitting a clarinet with a violin bow, or
a basketball with a golf club, out of my "Coming from Ruby" article
before it saw the light of day, but there are definitely some amusing
possibilities there :slight_smile:

I'm not sure what the programming language analog is, maybe memory
management in C or something.

A better analogy here might be playing a woodwind, where you have to
do your own "breath management" vs. playing a pipe organ, which has a
"breath collector!"

What about the old days, when you'd have an apprentice working the
bellows while you played?

David

···

On Wed, 24 Oct 2007, Rick DeNatale wrote:

On 10/23/07, Yossef Mendelssohn <ymendel@pobox.com> wrote:

On Oct 22, 6:12 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

On 10/22/07, David A. Black <dbl...@rubypal.com> wrote:

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
   * Advancing With Rails, Edison, NJ, November 6-9
   * Advancing With Rails, Berlin, Germany, November 19-22
   * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!