p " --> find_without_something"
user = User.find_without_something(1)

Can anyboby explain me what actully happens there. In my opinion,
‘find_without_something’ should represent the original ‘find’ method, so
there should not be any output. For a strange reason it outputs 0,0,1,1
which in fact means that it calls ‘find_with_something’ twice.

Can anyboby explain me what actully happens there. In my opinion,
‘find_without_something’ should represent the original ‘find’ method, so
there should not be any output. For a strange reason it outputs 0,0,1,1
which in fact means that it calls ‘find_with_something’ twice.

It might be something to do with the fact that the base find() method
calls itself recursively, which means your alias will intercept that
recursive call as well as the initial. Then again, it might not…

I’m trying to extend ActiveRecord’s find method (Rails 1.0, Ruby
1.8.2), but I recognize a strange behaviour of the “alias_method”
call.
I wrote a very simple script to explain my problem:

Don’t do that.

Use inheritance as Alan Kay Himself intended.

This aliasing is a very bad software engineering practice when you
have. When you alias you have no idea what the method call order is
unless you read each file and make at least a mental map of the call
order. (No, really, tell me what the call order for
ActionController::Base#process is.)

When you use inheritance the call order is explicit from the
inheritance chain.

When you use inheritance the call order is explicit from the inheritance
chain.
…mostly. Multiple inheritance can make a right dog’s dinner out of
it, because the call order then becomes dependent on the order of module
inclusion.

When you use inheritance the call order is explicit from the
inheritance chain.
…mostly. Multiple inheritance can make a right dog’s dinner out
of it, because the call order then becomes dependent on the order
of module inclusion.

Which is plainly visible via Module#ancestors.

But this is only using single inheritance, so I don’t see how that’s
relevant.

My problem is, how can I access the parent-class ‘find’ method? I can’t
just call ‘MyRecord.superclass.find(*args)’ because it would call
‘ActiveRecord::Base.find’ which is actually not the same as ‘SomeObject
.find’. If I try that I get ‘ActiveRecord::Base doesn’t belong in a
hierarchy descending from ActiveRecord’, as expected.

Are they any suggestions how the ActiveRecord’s ‘find’ method can
generally be extended in a ‘clean’ manner, without ‘aliasing’ (I’ve done
it similarly to the ‘acts_as_paranoid’ extension using aliasing, but
it’s rather a hack than clean coding).

My problem is, how can I access the parent-class ‘find’ method? I
can’t just call ‘MyRecord.superclass.find(*args)’ because it would
call ‘ActiveRecord::Base.find’ which is actually not the same as
‘SomeObject .find’. If I try that I get ‘ActiveRecord::Base doesn’t
belong in a hierarchy descending from ActiveRecord’, as expected.

super

Are they any suggestions how the ActiveRecord’s ‘find’ method can
generally be extended in a ‘clean’ manner, without ‘aliasing’ (I’ve
done it similarly to the ‘acts_as_paranoid’ extension using
aliasing, but it’s rather a hack than clean coding).

You should just make your own method: find_with_scope. Then in that
method you can add your scope to the :conditions and then sedn it
along its way to AR::Base.find. then you wont have any problems with
find calling itself recursively or other code or plugins trying to
override find and making your code explode.

In my new plugin that deals with building the :conditions hash with

pure ruby like syntax, I wanted to override find but found it much
better to make my own ez_find that did what it needed to do and then
called AR::Base.find with the new :conditions. Here is my code for
that, you could adopt something similar and put it in a plugin so you
caoul d use it in your other apps as well.:

module EZ
#
# EZ::Condition plugin for generating the :conditions where clause
# for ActiveRecord::Base.find. And an extension to
ActiveRecord::Base
# called AR::Base.find_with_conditions that takes a block and
builds
# the where clause dynamically for you.
#
def self.included(base)
base.extend(ClassMethods)
end

module ClassMethods
# The block recieves the condition for the model itself, as