Model Name Conflict

Rails
1

I have a model by the name Filter but due to the changes in reorganizing
the filters from 2.0.3, it is conflicting with the

ActionController::Filters::Filter (class)

In my filters_controller.rb when I try to find the filter

Filter.find(:id)

as rails is infering the ActionController::Filters::Filter class rather
than my model class Filter. Is there any work around other than renaming
my model?

BTW: If I use ActiveRecord::Base::Filter.find(:id) to load my filter
object, its working, but I am not quite sure if there are any unforseen
implications by doing this, when rails try to unload/reload constants.

Thanks in advance.

2

Use

::Filter.find(blah blah lbah)

to force Rails to look at your Filter class rather than
ActionController’s

3

Thanks Ar Chon for the prompt response. But that runs me to another
question.

How is Filter.find() different from ::Filter.find()?
What exactly does prefixing :: does?

I was under the impression that
Filter.find(),
self::Filter.find() and
::Filter.find()
all the same. What is the difference between them? and how does these
effect the Dependencies mechanism?

Hope that is not a lot to ask. Thanks in advance.
-Satynos
Ar Chron wrote:

Use

::Filter.find(blah blah lbah)

to force Rails to look at your Filter class rather than
ActionController’s

4

On Jun 2, 3:36 am, Saty N. [email protected] wrote:

Thanks Ar Chon for the prompt response. But that runs me to another
question.

How is Filter.find() different from ::Filter.find()?

::Filter makes ruby look from the top of the name space, so if you
have

module Foo
class Filter
end

def get_filter
::Filter
end
end

class Filter
end

then the :: means you get the top level Filter class rather than
Foo::Filter

Fred

5

Thanks for the clarification Frederick. So if I am not wrong top level
class is nothing but in the Object level space, isn’t it?

Also your lack of response for my other question “how does these effect
the Dependencies mechanism?”, I am assuming it shouldn’t be a problem.
As we are asking ruby to look for the top level class, it is the same as
asking Filter.find() as in the case we would generally do when there is
no conflicting class is my situation.

And finally I am assuming from the your example (with my additional
method):

module Foo
class Filter
end

def get_filter
::Filter
end

def get_my_filter
self::Filter (or)
Filter (same as self::Filter)
end
end

def get_outer_filter
self::Filter
end

class Filter
end

get_filter → returns outer class Filter
get_my_filter → returns Foo::Filter
get_outer_filter → returns outer class Filter

so self::Filter depends in the context of self. Any corrections are
appreciated.

-Satynos

Frederick C. wrote:

On Jun 2, 3:36�am, Saty N. [email protected] wrote:

Thanks Ar Chon for the prompt response. But that runs me to another
question.

How is Filter.find() different from ::Filter.find()?

::Filter makes ruby look from the top of the name space, so if you
have

module Foo
class Filter
end

def get_filter
::Filter
end
end

class Filter
end

then the :: means you get the top level Filter class rather than
Foo::Filter

Fred

6

On Jun 2, 2:45 pm, Saty N. [email protected] wrote:

Thanks for the clarification Frederick. So if I am not wrong top level
class is nothing but in the Object level space, isn’t it?

I believe so.

class Filter
end
get_outer_filter → returns outer class Filter

so self::Filter depends in the context of self. Any corrections are
appreciated.

Filter and self::Filter are not the same, because constants are looked
up lexically eg:

module Foo
class Filter
def self.name; ‘inner’; end
end

def self.included(base)
base.extend(ClassMethods)
end
module ClassMethods
def with_self
self::Filter
end

def bare
  Filter
end

end
end

class Bar
class Filter
def self.name; ‘from bar’; end
end
include Foo
end

Then Bar.bare.name #=> “inner”
Bar.with_self.name #=> “from bar”

Fred

7

Thanks for the nice feedback and clearing up the things.

-Satynos