[#1094] Re: [ruby-cvs] ruby, ruby/lib: * eval.c (ev_const_defined, ev_const_get), variable.c — Dave Thomas <dave@...>

> * eval.c (rb_mod_autoload, rb_mod_autoload_p): new method;

12 messages 2003/05/29
[#1095] Re: [ruby-cvs] ruby, ruby/lib: * eval.c (ev_const_defined, ev_const_get), variable.c — nobu.nokada@... 2003/05/29

Hi,

Re: irb doesn't work, because tempfile doesn't work

From: Dave Thomas <dave@...>
Date: 2003-05-02 16:48:13 UTC
List: ruby-core #1006
Yukihiro Matsumoto wrote:
> |Is this because of the 'instance_methods' change?
> 
> Yes.  I thought they should be consistent with Object#methods.

FWIW, I always thought that Object#methods should have accepted a 
'recurse' parameter and that it should have defaulted to 'false'. In 
daily use, I seem to care more about the methods actually defined in an 
object's class than those methods it responds to.

For example, when looking at the complex/rational problem, I needed to 
be able to find out if the method 'power!' was defined in a particular 
class (but only in that class: I didn't care about ancestors). I 
couldn't find a neat way, and resorted to 
instance_methods.include?("power!"), which seemed ugly.

So, if we're making things incompatible, I'd like to suggest a more 
global change. Make _all_ the reflection methods accept a 'recurse' 
parameter (including things such as method_defined?), and have that 
parameter default to the current 1.6.x behavior. As it stands right now 
we have a curious mixture: some allow you recurse, some let you specify 
it, and some don't recurse.

By making the parameter default to the current behavior, we retain 
compatibility for all the developers out there, but by providing the 
parameter we give ourselves future flexibility.


Cheers


Dave



In This Thread