chrisjroos@gmail.com
9/16/2006 9:26:00 AM
> >
> > It struck me that it might be quite useful to wrap this up and apply
> > it to all methods defined for [a] given class[es]. Unfortunately, it
> > appears not to be (completely) possible. I thought we might be able
> > to use the method_added hook, but this gets fired after the method
> > definition. We need something to fire right before the method
> > definition. As def is a keyword and not a method, we can't override
> > and add to the default behaviour. Note, that we can, however, do this
> > with define_method.
>
> 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