Well, the Extensions project does this.
I just had a look at the extensions project (albeit briefly) and can
only see Object#define_method. I don’t think this does what I was
after. To clarify, I’m thinking (and Jim was addressing) of the case
where we import multiple libraries from different places. There is no
easy way of knowing whether two libraries modify the same class
(stdlib or otherwise) in an incompatible manner. We’ve actually
experienced this at work a couple of times. I recall at one point
ending up with two String#stem methods defined by different libs.
It’d be nice if, on redefining an existing method, we could get a
warning to allow us a quicker route to the problem.
This, in particular, is the problem that cannot be solved using the
def keyword but can be solved using define_method.
class Module
def existing_method?(sym)
instance_method(sym) rescue nil # seems like the easiest way to
find if a method exists in any of the public, protected, private
scopes
end
alias :define_method_before_nasty_hack :define_method
def define_method(sym, &block)
puts “Warning: Overriding existing method definition
#{self}##{sym}” if existing_method?(sym)
define_method_before_nasty_hack(sym, &block)
end
end
class Foo
define_method(:foo) do
p ‘foo’
end
end
No warning generated at this point
class Foo
define_method(:foo) do
p ‘new foo’
end
end
#=> Warning: Overriding existing method definition Foo#foo
And another way to avoid it is
to use a module instead of adding the method directly, a la
ActiveSupport.
I don’t quite understand how this helps, maybe you can explain?
But, I can’t say I see the point exactly. Maybe I
missing a usecase. But first of all it would only really matter if
you’re bringing in a whole mess of methods all at once and thus are not
sure what you are getting, otherwise you would have avoided the clash
yourself. Plus it shouldn’t matter al all if you require the extensions
FIRST. After all, it’s presumed you’re going to use the extensions but
if you need to use one of the already used method names you’re code can
just overwrite the extension definition --rather than the other way
around. Also, what if you actaully want it to override the method?
Re, if you actually want to override the method and don’t want
warnings. I’d suggest that this functionality be implemented in it’s
own lib (similar to whiny_nils in rails) that can be required as a
debugging tool maybe.
So, my actual question is, why are some things keywords and most
things method calls? I think it’s io (language) that doesn’t have any
keywords at all (so I guess it must be possible). In addition, I’m
interested in whether there are there any plans to increase or
decrease the number of keywords in ruby?
Seems like there’s rather few as it is, but in anycase it’s unlikely to
increase. Of course that’s up to Matz.
I have a figure in my head of around 40 keywords - that may be
inaccurate. I’m still interested in general as to why the language
would implement somethings as keywords? I’m guessing it could be to
do with efficiency.
Thanks for the responses so far folks.
Cheers,
Chris
