#respond_to? not working for dynamically generated methods

[Maurice Gladwell]

It seems Object#respond_to doesn't work for dynamically generated
methods:

SomeRailsModel.respond_to? 'find_by_name' #=> false

1. Is there some way to *really* check if an object will respond to a
message, even if it will respond by a dynamically generated method?

Right now, Object#respond_to? just doesn't do what it name promises: it
doesn't check if an object responds to a message :foo, only if the
object has a :foo method defined.

Thanks,
Maurice B. Gladwell

 

[Stefano Crocco]

Alle mercoled=C3=AC 30 maggio 2007, Maurice Gladwell ha scritto:

It seems Object#respond_to doesn't work for dynamically generated
methods:

SomeRailsModel.respond_to? 'find_by_name' #=3D> false

1. Is there some way to *really* check if an object will respond to a
message, even if it will respond by a dynamically generated method?

Right now, Object#respond_to? just doesn't do what it name promises: it
doesn't check if an object responds to a message :foo, only if the
object has a :foo method defined.

Thanks,
Maurice B. Gladwell

Are you sure find_by_name is a class method and not an instance method (i.e=
,=20
do you call SomeRailsModel.find_by_name or something like=20
SomeRailsModel.new.find_by_name)? I don't know Rails, so I may be wrong, bu=
t=20
to me it seems that find_by_name is an instance method. If it is so, then y=
ou=20
can't expect SomeRailsModel.respond_to? to return true. This has nothing to=
=20
do with the method being dynamically generated. For instance,

Array.respond_to?select)

gives false, because select is an instance method.

Array.new.respond_to?select)

gives true, instead.

If you want to know whether a class has an *instance* method without first=
=20
creating an instance of the class, you can call instance_methods on the=20
class. It will return an array with the names of the methods instances of t=
he=20
class will have. For example:

Array.instance_methods
=3D>["select", "[]=3D", "inspect", "<<", ... ]

In your case, if find_by_name is an instance method, you can do this:

SomeRailsModel.instance_methods.include? 'find_by_name'

I hope this helps

Stefano

 

[Maurice Gladwell]

Are you sure find_by_name is a class method and not an instance method

Yes, I'm positive:
=> false
=> #<SomeRailsModelname='foo'>

M.

 

[Nobuyoshi Nakada]

Hi,

At Wed, 30 May 2007 18:01:59 +0900,
Stefano Crocco wrote in [ruby-talk:253530]:

In your case, if find_by_name is an instance method, you can do this:

SomeRailsModel.instance_methods.include? 'find_by_name'

method_defined? would be better in almost cases.

 

[Sascha Abel]

It seems Object#respond_to doesn't work for dynamically generated
methods:

SomeRailsModel.respond_to? 'find_by_name' #=> false

1. Is there some way to *really* check if an object will respond to a
message, even if it will respond by a dynamically generated method?

Right now, Object#respond_to? just doesn't do what it name promises: it
doesn't check if an object responds to a message :foo, only if the
object has a :foo method defined.

Thanks,
Maurice B. Gladwell

I think 'Object#respond_to?' just looks at a list of previously
*defined* methods, as does 'method_defined?', it doesn't matter if
they're defined dynamically at runtime or not. 'find_by_name' is not
really a method in Rails, it's just the magic of method_missing that you
can call it on SomeRailsModel.

In order to find out which methods SomeRailsModel would respond to you'd
have to write a method that looks at 'method_missing' and works out all
the possibilities there. I'm by no means an expert (neither for Ruby nor
Rails), but SomeRailsModel will respond to every 'find_by_foo' method,
where foo is column of the underlying database, so your task seems way
too big for such like me..

Sascha

 

[dblack]

Hi --

It seems Object#respond_to doesn't work for dynamically generated
methods:

SomeRailsModel.respond_to? 'find_by_name' #=> false

1. Is there some way to *really* check if an object will respond to a
message, even if it will respond by a dynamically generated method?

Right now, Object#respond_to? just doesn't do what it name promises: it
doesn't check if an object responds to a message :foo, only if the
object has a :foo method defined.

That's what responding to a method means. Otherwise, it would be
meaningless, since you can send any message to any object.

Things like find_by_name are made possible by method_missing, which
intercepts uninterpretable messages. It's possible for method_missing
to generate a new method dynamically, but it doesn't have to (and in
fact "find_by_name" does not get generated as a method; it just gets
examined as a string). Even if it does, there's no way for respond_to
to figure it out.

Basically, to know what's going to happen dynamically, you have to run
the program and send the messages.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Daniel DeLorme]

Basically, to know what's going to happen dynamically, you have to run
the program and send the messages.

Or you have to patch rails so that respond_to? will take this case into
account. It's open source, what are you waiting for? ;-)

Daniel

 

[Robert Dober]

Hi --

Does not look right though

# vim: sts=2 sw=2 expandtab nu tw=0:


module M
def m; "m" end
end
class A
def a; "a" end
end

class B < A
include M
end

b = B.new
def b.b; "b" end

p B.new.respond_to?a)
p B.new.respond_to?m)
p B.method_defined?a)
p B.method_defined?m)
p b.respond_to?b)
true
true
true
true
true

looks pretty good to me.
Is Rails fooling around with my beloved Ruby ?
For what concerns intercepted messages for which no methods exist
David has said it all below:...

That's what responding to a method means. Otherwise, it would be
meaningless, since you can send any message to any object.

Things like find_by_name are made possible by method_missing, which
intercepts uninterpretable messages. It's possible for method_missing
to generate a new method dynamically, but it doesn't have to (and in
fact "find_by_name" does not get generated as a method; it just gets
examined as a string). Even if it does, there's no way for respond_to
to figure it out.

Basically, to know what's going to happen dynamically, you have to run
the program and send the messages.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

Cheers
Robert

 

[dblack]

Hi --

Does not look right though

# vim: sts=2 sw=2 expandtab nu tw=0:


module M
def m; "m" end
end
class A
def a; "a" end
end

class B < A
include M
end

b = B.new
def b.b; "b" end

p B.new.respond_to?a)
p B.new.respond_to?m)
p B.method_defined?a)
p B.method_defined?m)
p b.respond_to?b)
true
true
true
true
true

looks pretty good to me.
Is Rails fooling around with my beloved Ruby ?

No, it's just using method_missing, which intercepts the
"find_by_name" message.

For what concerns intercepted messages for which no methods exist
David has said it all below:...

I'll go along with that


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Maurice Gladwell]

[...]
Basically, to know what's going to happen dynamically, you have to run
the program and send the messages.

It would be possible to define at writing time the entire range of
messages that an object will respond to. Here's how:

There are two kinds of messages to which an object responds by something
that is not a NoMethodError:

1) Those corresponding to defined instance methods.

2) Those that are handled in some way by method_missing.

#1 is already well defined and thus handled by #respond_to?. So if we
could just define the range of messages recognized by method_missing, we
could have an object return the entire range of messages to which it
will respond.

Of course, we don't have standard support for that currently, but we
could (e.g. with some DSL) declare inside the class definition (e.g.
above the `def method_missing`) patterns to which method_missing would
respond.

So for example, in ActiveRecord::Base we would have something like:

responds_to /find_by_.+/

Thus `SomeRailsModel.respond_to? :find_by_name` would have the knowledge
it needs to return the correct answer: true.

 

[Robert Dober]

No, it's just using method_missing, which intercepts the
"find_by_name" message.

Ok that is acceptable thx for the clarification.

I'll go along with that

We are risking recursive mutual agreement causing stack overflow
Cheers
Robert

 

[dblack]

Hi --

[...]
Basically, to know what's going to happen dynamically, you have to run
the program and send the messages.

It would be possible to define at writing time the entire range of
messages that an object will respond to. Here's how:

There are two kinds of messages to which an object responds by something
that is not a NoMethodError:

1) Those corresponding to defined instance methods.

2) Those that are handled in some way by method_missing.

That's every possible string you can sent to an object.

#1 is already well defined and thus handled by #respond_to?. So if we
could just define the range of messages recognized by method_missing, we
could have an object return the entire range of messages to which it
will respond.

Of course, we don't have standard support for that currently, but we
could (e.g. with some DSL) declare inside the class definition (e.g.
above the `def method_missing`) patterns to which method_missing would
respond.

So for example, in ActiveRecord::Base we would have something like:

responds_to /find_by_.+/

Thus `SomeRailsModel.respond_to? :find_by_name` would have the knowledge
it needs to return the correct answer: true.

That's a bit of a conversation-stopper But I'll just observe that
"responding to a message" is really a kind of high-level, abstract way
of saying that the object has a method it can run whose name
corresponds to the message. That's not true of "find_by_name" in the
case of an ActiveRecord::Base subclass; there is no such method, and
the only way an object can handle the message is with method_missing,
which is not the same as the message itself being understood by the
object.

You could of course shoehorn find_by_* into respond_to? for AR
objects, if you don't mind, essentially, writing method_missing twice
(once for real, once as a kind of pseudo-static twin). But in the
general case, method_missing really means it's missing, and it's
handled at the time in ways that cannot be predicted or registered
with the system in advance. For example:

class C
def method_missing(m)
super unless rand(2).zero?
puts "I'm handing your message!"
end
end

c = C.new

Does c respond to "blah"?

In sum, the way it's engineered, with objects responding to certain
messages (in the sense of having corresponding methods), and
method_missing available to handle the missing ones, gives you more
latitude and flexibility than you'd be able to encapsulate in a
missing-method registry.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[James Edward Gray II]

You could of course shoehorn find_by_* into respond_to? for AR
objects, if you don't mind, essentially, writing method_missing twice
(once for real, once as a kind of pseudo-static twin).

I don't really understand this stance. My opinion is that providing
a method_missing() implementation is a convenient way for a
programmer to define a lot of dynamic methods. This increases the
messages an object responds to.

Following from that logic, I believe you should also override
respond_to?() to reflect those new messages. It's my opinion
therefore that this thread has exposed a bug in Rails that should be
patched.

As for the double implementation, I would think we would handle that
in the usual way. You use an Extract Method refactoring to pull out
the matching logic into a separate private method and use that in
both implementations.

Those are just my opinions though.

James Edward Gray II

 

[Robert Dober]

I don't really understand this stance. My opinion is that providing
a method_missing() implementation is a convenient way for a
programmer to define a lot of dynamic methods. This increases the
messages an object responds to.

I have always felt that dynamic method creation and dynamic message
interception are not quite the same beast. But I guess you have some
thoughts behind your claim of which I fail to grasp the concept. Would
you mind to elaborate?

To be honest, with my lack of imagination, right now I really do not
like the idea to tweak #respond_to? .

Am I right that in the following case

class A
def method_missing name, *args, &blk
return whatever(name, *args, &blk)
end
end

A.new.respond_to(x) would be true for whatever x - if it were for your idea.

Is this really a good idea?

Cheers
Robert

Those are just my opinions though. Same here

James Edward Gray II

Robert

 

[Brian Candler]

Of course, we don't have standard support for that currently, but we
could (e.g. with some DSL) declare inside the class definition (e.g.
above the `def method_missing`) patterns to which method_missing would
respond.

So for example, in ActiveRecord::Base we would have something like:

responds_to /find_by_.+/

Hmm, everybody forgets to anchor their regular expressions

Anyway, this doesn't seem right. find_by_foo will fail if there is no column
called 'foo'. So really you should really check that the column exists.

But that doesn't work either, when you remember that AR also supports
find_by_foo_and_bar(x,y), find_by_foo_and_bar_and_baz(x,y,z) etc.

It would be too expensive to enumerate all these possibilities up-front.
Rather, I think you need to check whether a particular method name is valid
or not. In which case, what you really want is to define a respond_to?
method in ActiveRecord::Base which has the same logic as 'find'.

class ActiveRecord::Base
alias :respond_to :real_respond_to
def respond_to?(m)
return true if real_respond_to?(m)

# now also return true if m is of the form find_xxxxxxxx and
# xxxxxx is a valid finder pattern
end
end

Regards,

Brian.

 

[James Edward Gray II]

I have always felt that dynamic method creation and dynamic message
interception are not quite the same beast. But I guess you have some
thoughts behind your claim of which I fail to grasp the concept. Would
you mind to elaborate?

I'm not really sure what else to say. I read the documentation for
respond_to?():

$ ri -T Object#respond_to?
----------------------------------------------------- Object#respond_to?
obj.respond_to?(symbol, include_private=false) => true or false
------------------------------------------------------------------------
Returns +true+> if _obj_ responds to the given method. Private
methods are included in the search only if the optional second
parameter evaluates to +true+.

I know that ActiveRecord model classes will except find_by_*()
methods, so the fact that respond_to?() returns false for them makes
the above documentation lie. That does not seem good to me and it's
certainly possible to fix it. Thus, I can only reason that it is a
bug in ActiveRecord.

Is this really a good idea?

Is it a good idea not to? What exactly is the use case for
respond_to?()? I have only ever used it to find out if something I
want is available. If I can't do that reliably, it doesn't really
help me much.

James Edward Gray II

 

[Maurice Gladwell]

I don't really understand this stance. My opinion is that providing
a method_missing() implementation is a convenient way for a
programmer to define a lot of dynamic methods. This increases the
messages an object responds to.

I must agree with James Edward Gray here.

David's contrived example is of course possible, but highly unlikely in
practice; a programmer will generally not code his program into a
situation in which he can't be sure whether an object will respond to a
particular message sent to it. That's probably a major reason for having
Object#respond_to?.

In practice, and certainly in the Rails' find_by_* case, you have a
well-defined range of messages to which an object will respond, known
already at development time. I don't know of a single real-life example
in which a programmer doesn't know at development time the entire range
of messages his objects might respond to. And Rails - with all its magic
- notwithstanding.

--
M.

(Of course, even if there would be an exception to that rule, in which
we really cannot delimit - for reasons unimaginable - the range of
messages to which the object will respond to at runtime - that rare and
probably bizarre case would not obviate the usefulness of the other
99.99% more common cases.)

 

[Brian Candler]

I must agree with James Edward Gray here.

David's contrived example is of course possible, but highly unlikely in
practice; a programmer will generally not code his program into a
situation in which he can't be sure whether an object will respond to a
particular message sent to it. That's probably a major reason for having
Object#respond_to?.

As an edge case, consider a DRb client proxy object. Should respond_to? be
handled locally, or should it be proxied to the server? This involves an
expensive network round trip.

In many cases it may be cheaper to attempt the call and to rescue a
NoMethodError, than to have 'respond_to?' perform almost as much work as the
call you're testing.

Regards,

Brian.

 

[James Edward Gray II]

As an edge case, consider a DRb client proxy object. Should
respond_to? be
handled locally, or should it be proxied to the server? This
involves an
expensive network round trip.

In many cases it may be cheaper to attempt the call and to rescue a
NoMethodError, than to have 'respond_to?' perform almost as much
work as the
call you're testing.

I agree with everything you just said and it still doesn't convince
me respond_to?() should lie. Whether or not we use respond_to?()
in a given situation seems like an entirely different issue to me.

James Edward Gray II

 

[dblack]

Hi --

I must agree with James Edward Gray here.

David's contrived example is of course possible, but highly unlikely in
practice; a programmer will generally not code his program into a
situation in which he can't be sure whether an object will respond to a
particular message sent to it. That's probably a major reason for having
Object#respond_to?.

But it can happen; hence NoMethodError.

In practice, and certainly in the Rails' find_by_* case, you have a
well-defined range of messages to which an object will respond, known
already at development time. I don't know of a single real-life example
in which a programmer doesn't know at development time the entire range
of messages his objects might respond to. And Rails - with all its magic
- notwithstanding.

If it's absolutely known what messages every object will respond to,
then we don't need #respond_to? I don't know... it's obviously
just a slightly different way of looking at it. I'm uneasy with
having to rewrite respond_to? every time I implement method_missing;
it seems like a lot of work and an awfully tight coupling.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)