Retrieve list of instance methods that are defined in rails class excluding inherited and included methods
up vote
1
down vote
favorite
I have a class Product in my rails project, I am trying to retrieve a list of instance methods of my class that are defined in my file (not inherited method or included via mixin). Here's a small sample of my class :
class Product
include Mongoid::Document
include Mongoid::Paperclip
include Mongoid::Search
include Mongoid::Slug
include Mongoid::Timestamps
extend Enumerize
def product_image
image.url(:small) unless image.nil?
end
def product_school_level
self.school_levels.join ' | '
end
def product_grades
self.grades.where(degree_ids: nil).pluck(:name).uniq.join ' | '
end
end
I tried to use Product.instance_methods(false)
. However this still returns a lot of methods I dont need, here's a little sample :
:_run_post_process_callbacks,
:aliased_fields,
:_post_process_callbacks,
:_run_image_post_process_callbacks,
:_image_post_process_callbacks,
:_validation_callbacks,
:nested_attributes?,
:_run_touch_callbacks,
:readonly_attributes?,
:_run_save_callbacks,
:aliased_fields?,
:_save_callbacks,
:localized_fields?,
:readonly_attributes,
:fields?,
:pre_processed_defaults?,
:_update_callbacks,
:post_processed_defaults?,
:fields,
:_id_default
I ran Product.new.method(:_run_post_process_callbacks).source_location
on a few of these methods to try to check where they come from. It seems they all come from active_support.
I never included active_support in my class, so I guess classes in a rails project automatically include active_supports methods ? How is that possible without any inheritance syntax (<<) or include syntax ?
How can I then achieve what I want to do and get rid of these methods I dont need in my list ?
ruby-on-rails ruby inheritance mixins activesupport
add a comment |
up vote
1
down vote
favorite
I have a class Product in my rails project, I am trying to retrieve a list of instance methods of my class that are defined in my file (not inherited method or included via mixin). Here's a small sample of my class :
class Product
include Mongoid::Document
include Mongoid::Paperclip
include Mongoid::Search
include Mongoid::Slug
include Mongoid::Timestamps
extend Enumerize
def product_image
image.url(:small) unless image.nil?
end
def product_school_level
self.school_levels.join ' | '
end
def product_grades
self.grades.where(degree_ids: nil).pluck(:name).uniq.join ' | '
end
end
I tried to use Product.instance_methods(false)
. However this still returns a lot of methods I dont need, here's a little sample :
:_run_post_process_callbacks,
:aliased_fields,
:_post_process_callbacks,
:_run_image_post_process_callbacks,
:_image_post_process_callbacks,
:_validation_callbacks,
:nested_attributes?,
:_run_touch_callbacks,
:readonly_attributes?,
:_run_save_callbacks,
:aliased_fields?,
:_save_callbacks,
:localized_fields?,
:readonly_attributes,
:fields?,
:pre_processed_defaults?,
:_update_callbacks,
:post_processed_defaults?,
:fields,
:_id_default
I ran Product.new.method(:_run_post_process_callbacks).source_location
on a few of these methods to try to check where they come from. It seems they all come from active_support.
I never included active_support in my class, so I guess classes in a rails project automatically include active_supports methods ? How is that possible without any inheritance syntax (<<) or include syntax ?
How can I then achieve what I want to do and get rid of these methods I dont need in my list ?
ruby-on-rails ruby inheritance mixins activesupport
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a class Product in my rails project, I am trying to retrieve a list of instance methods of my class that are defined in my file (not inherited method or included via mixin). Here's a small sample of my class :
class Product
include Mongoid::Document
include Mongoid::Paperclip
include Mongoid::Search
include Mongoid::Slug
include Mongoid::Timestamps
extend Enumerize
def product_image
image.url(:small) unless image.nil?
end
def product_school_level
self.school_levels.join ' | '
end
def product_grades
self.grades.where(degree_ids: nil).pluck(:name).uniq.join ' | '
end
end
I tried to use Product.instance_methods(false)
. However this still returns a lot of methods I dont need, here's a little sample :
:_run_post_process_callbacks,
:aliased_fields,
:_post_process_callbacks,
:_run_image_post_process_callbacks,
:_image_post_process_callbacks,
:_validation_callbacks,
:nested_attributes?,
:_run_touch_callbacks,
:readonly_attributes?,
:_run_save_callbacks,
:aliased_fields?,
:_save_callbacks,
:localized_fields?,
:readonly_attributes,
:fields?,
:pre_processed_defaults?,
:_update_callbacks,
:post_processed_defaults?,
:fields,
:_id_default
I ran Product.new.method(:_run_post_process_callbacks).source_location
on a few of these methods to try to check where they come from. It seems they all come from active_support.
I never included active_support in my class, so I guess classes in a rails project automatically include active_supports methods ? How is that possible without any inheritance syntax (<<) or include syntax ?
How can I then achieve what I want to do and get rid of these methods I dont need in my list ?
ruby-on-rails ruby inheritance mixins activesupport
I have a class Product in my rails project, I am trying to retrieve a list of instance methods of my class that are defined in my file (not inherited method or included via mixin). Here's a small sample of my class :
class Product
include Mongoid::Document
include Mongoid::Paperclip
include Mongoid::Search
include Mongoid::Slug
include Mongoid::Timestamps
extend Enumerize
def product_image
image.url(:small) unless image.nil?
end
def product_school_level
self.school_levels.join ' | '
end
def product_grades
self.grades.where(degree_ids: nil).pluck(:name).uniq.join ' | '
end
end
I tried to use Product.instance_methods(false)
. However this still returns a lot of methods I dont need, here's a little sample :
:_run_post_process_callbacks,
:aliased_fields,
:_post_process_callbacks,
:_run_image_post_process_callbacks,
:_image_post_process_callbacks,
:_validation_callbacks,
:nested_attributes?,
:_run_touch_callbacks,
:readonly_attributes?,
:_run_save_callbacks,
:aliased_fields?,
:_save_callbacks,
:localized_fields?,
:readonly_attributes,
:fields?,
:pre_processed_defaults?,
:_update_callbacks,
:post_processed_defaults?,
:fields,
:_id_default
I ran Product.new.method(:_run_post_process_callbacks).source_location
on a few of these methods to try to check where they come from. It seems they all come from active_support.
I never included active_support in my class, so I guess classes in a rails project automatically include active_supports methods ? How is that possible without any inheritance syntax (<<) or include syntax ?
How can I then achieve what I want to do and get rid of these methods I dont need in my list ?
ruby-on-rails ruby inheritance mixins activesupport
ruby-on-rails ruby inheritance mixins activesupport
asked Nov 19 at 13:24
David Geismar
79321336
79321336
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
Many (most? all?) of those extra methods you are seeing are being created using Module#define_method
. If you dig deep in the source for active_support
, you'll see that. (You aren't directly including active_support
, but it's being pulled in by one or more of the Mongoid
modules.)
So these are in fact valid instance methods of your model class, which is why they are included in instance_methods(false)
. Other methods that are defined "conventionally" in the mixins, such as #freeze
, are reported by instance_methods(true)
, but not by instance_methods(false)
.
I think you may have to do something to filter the list based on the source location. Something along these lines:
my_methods = Product.instance_methods(false).select do |m|
Product.instance_method(m).source_location.first.ends_with? '/product.rb'
end
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned byChild.instance_methods(false)
– David Geismar
Nov 21 at 10:17
1
@DavidGeismar. Yes,define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact techniqueactive_support
is using, but the effect is the same.)
– showaltb
Nov 22 at 17:40
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Many (most? all?) of those extra methods you are seeing are being created using Module#define_method
. If you dig deep in the source for active_support
, you'll see that. (You aren't directly including active_support
, but it's being pulled in by one or more of the Mongoid
modules.)
So these are in fact valid instance methods of your model class, which is why they are included in instance_methods(false)
. Other methods that are defined "conventionally" in the mixins, such as #freeze
, are reported by instance_methods(true)
, but not by instance_methods(false)
.
I think you may have to do something to filter the list based on the source location. Something along these lines:
my_methods = Product.instance_methods(false).select do |m|
Product.instance_method(m).source_location.first.ends_with? '/product.rb'
end
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned byChild.instance_methods(false)
– David Geismar
Nov 21 at 10:17
1
@DavidGeismar. Yes,define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact techniqueactive_support
is using, but the effect is the same.)
– showaltb
Nov 22 at 17:40
add a comment |
up vote
2
down vote
accepted
Many (most? all?) of those extra methods you are seeing are being created using Module#define_method
. If you dig deep in the source for active_support
, you'll see that. (You aren't directly including active_support
, but it's being pulled in by one or more of the Mongoid
modules.)
So these are in fact valid instance methods of your model class, which is why they are included in instance_methods(false)
. Other methods that are defined "conventionally" in the mixins, such as #freeze
, are reported by instance_methods(true)
, but not by instance_methods(false)
.
I think you may have to do something to filter the list based on the source location. Something along these lines:
my_methods = Product.instance_methods(false).select do |m|
Product.instance_method(m).source_location.first.ends_with? '/product.rb'
end
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned byChild.instance_methods(false)
– David Geismar
Nov 21 at 10:17
1
@DavidGeismar. Yes,define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact techniqueactive_support
is using, but the effect is the same.)
– showaltb
Nov 22 at 17:40
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Many (most? all?) of those extra methods you are seeing are being created using Module#define_method
. If you dig deep in the source for active_support
, you'll see that. (You aren't directly including active_support
, but it's being pulled in by one or more of the Mongoid
modules.)
So these are in fact valid instance methods of your model class, which is why they are included in instance_methods(false)
. Other methods that are defined "conventionally" in the mixins, such as #freeze
, are reported by instance_methods(true)
, but not by instance_methods(false)
.
I think you may have to do something to filter the list based on the source location. Something along these lines:
my_methods = Product.instance_methods(false).select do |m|
Product.instance_method(m).source_location.first.ends_with? '/product.rb'
end
Many (most? all?) of those extra methods you are seeing are being created using Module#define_method
. If you dig deep in the source for active_support
, you'll see that. (You aren't directly including active_support
, but it's being pulled in by one or more of the Mongoid
modules.)
So these are in fact valid instance methods of your model class, which is why they are included in instance_methods(false)
. Other methods that are defined "conventionally" in the mixins, such as #freeze
, are reported by instance_methods(true)
, but not by instance_methods(false)
.
I think you may have to do something to filter the list based on the source location. Something along these lines:
my_methods = Product.instance_methods(false).select do |m|
Product.instance_method(m).source_location.first.ends_with? '/product.rb'
end
answered Nov 19 at 15:20
showaltb
72836
72836
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned byChild.instance_methods(false)
– David Geismar
Nov 21 at 10:17
1
@DavidGeismar. Yes,define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact techniqueactive_support
is using, but the effect is the same.)
– showaltb
Nov 22 at 17:40
add a comment |
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned byChild.instance_methods(false)
– David Geismar
Nov 21 at 10:17
1
@DavidGeismar. Yes,define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact techniqueactive_support
is using, but the effect is the same.)
– showaltb
Nov 22 at 17:40
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned by
Child.instance_methods(false)
– David Geismar
Nov 21 at 10:17
I dont understand your explication about Module#define_method : apidock.com/ruby/Module/define_method. I have checked it, and actually when you use define_method in a Parent class or in a module that is mixed in later, then the method is not returned by
Child.instance_methods(false)
– David Geismar
Nov 21 at 10:17
1
1
@DavidGeismar. Yes,
define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact technique active_support
is using, but the effect is the same.)– showaltb
Nov 22 at 17:40
@DavidGeismar. Yes,
define_method
can be used to define a method in the including class. Here's an example of how it can be done: gist.github.com/showaltb/da9e8773211f9e7b62d2a52ec2047eb2. (This isn't the exact technique active_support
is using, but the effect is the same.)– showaltb
Nov 22 at 17:40
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53375616%2fretrieve-list-of-instance-methods-that-are-defined-in-rails-class-excluding-inhe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown