FIle module.rb
module CardExpiry
def check_expiry value
return true
end
end
file include.rb
#raise File.dirname(__FILE__).inspect
require "#{File.dirname(__FILE__)}/module.rb"
module Include
include CardExpiry
def self.function
raise (check_expiry 1203).inspect
end
end
calling
Include::function
is this possible ?
Error trigger when calling :
`function': undefined method `check_expiry' for Include:Module (NoMethodError)
You stumbled over the difference of include and extend.
include makes the method in the included module available to instances of your class
extend makes the methods in the included module available in the class
When defining a method with self.method_name and you access self within that method, self is bound to the current class.
check_expiry, however, is included and thus only available on the instance side.
To fix the problem either extend CardExpiry, or make check_expiry a class method.
I've looked at your problem in a bit more detail, and the issue is your module.rb file:
module CardExpiry
def self.check_expiry value
return true
end
end
First, there was an end missing from the file - both def and module need to be closed.
Second, the magical self. in the def line turns the method into a pseudo-global function - this answer explains it better than I can.
Furthermore, to call the method, you need to use:
raise (CardExpiry::check_expiry 1203).inspect
Related
I've been going through some tutorials to find this information, but haven't seen anything that directly addresses it.
I've seen several times on modules the following syntax:
module MyModule
def run()
puts "running"
end
end
I've also seen syntax that looks like this:
module MyModule
def MyModule.run()
puts "running"
end
end
What's the advantage to including the module name before the method and vice versa?
module MyModule
def MyModule.run()
puts "running"
end
end
is exactly the same as:
module MyModule
def self.run()
puts "running"
end
end
Usually def self.run is used, because it's better when you have to change the module name and it's more idiomatic. I don't see any advantages in writing def MyModule.run.
This has nothing to do with modules. This is just normal method definition syntax.
The syntax for a method definition in Ruby is
def <target>.<selector>(<parameters>)
# …
end
For example:
def foo.bar(baz)
end
This will define a method named bar on the object referenced by foo (more precisely, in the singleton class of the object referenced by foo), with a single mandatory positional parameter whose binding is named baz.
Like with message sends, you can leave out the target, and Ruby will use an implicit default. In a message send, the implicit default is self, with a method definition, the default is the so-called default definee, which is usually the closest lexically enclosing module definition body.
So,
def MyModule.run
means "define a method named run on the object MyModule (or more precisely in the singleton class of the object MyModule)", whereas
def run
means "define a method named run in the default definee", i.e. the closest lexically enclosing module definition body, which in this case is MyModule.
The second version defines run as an instance method of MyModule, the first version defines run as an instance method of the singleton class of MyModule, which we sometimes call a "module method" or "module function".
Note that the first version is usually more idiomatically written as
def self.run
This is about using a module as a static namespace vs using a module as a mixin. Have a look at the following code (with output in comments):
module MyModule
def MyModule.run()
puts "#{self}: running"
end
def run()
puts "#{self}: running"
end
end
class Foo
include MyModule
end
MyModule.run #MyModule: running
foo = Foo.new
foo.run #<Foo:0x007f9b269bf028>: running
In the first usage, the module is basically just acting as a namespace to which you attach a method.
In the second, the module is mixed in to the class Foo. This means that it acts as if the run method was defined within the foo class in the first place; you could, if you wished, refer to instance variables #bar which aren't defined in the module, but only in the Foo class.
I guess both are same but in case when we call module method inside class then we have to give
ModuleName.method_name()
So that it can understand that this method is required for included or that particular module
module Add
def addition
sum=1+2
puts sum
end
a=Add.addition
Can anyone tell me what I'm missing and why I am getting this error->
undefined method `addition' for Add:Module (NoMethodError)
You are confusing class methods and instance methods. Your definition:
module Add
def addition
...
end
end
defines methods on instances of Add whereas you called a method on the module Add. If you want to define a class/module method, you need to define like:
module Add
def self.addition
...
end
end
If you want to be able to call it directly, define it as a directly accessible method:
def self.addition
# ...
end
Or you can always rework this using:
module Add
# ...(methods)...
extend self
end
Where that will automatically promote all mixin-type methods as being directly accessible.
You can also tag them more selectively like this:
module Add
def addition
# ...
end
module_method :addition
end
That method is then available either as Add.addition or if some other module or class calls include Add.
I am a beginner in ruby.
I've tried to run this code and it shows run time error.
What's wrong with this code?
class Calc
attr_accessor :val1, :val2
def initialize (val1,val2)
#val1=val1
#val2=val2
end
end
a=Calc.new(2,3)
a.add_two_numbers(3)
def add_two_numbers(v3)
return #val1+#val2+v3
end
The method add_two_numbers is not defined on the class Calc, however you are using it as if it is. This is the problem.
I would presume you got a NoMethodError.
Update: As pointed out in the comments, in actuallity, the method is defined on the Object class by default, which then gets auto inherited into all classes, but as private. This actually means that you will be getting the error saying that a private method is being called. The fix remains the same, since the overarching problem is a confusion in how to define classes and their methods.
The fix would be to define the method on the class, by putting it in the class body.
class Calc
attr_accessor :val1, :val2
def initialize (val1,val2)
#val1=val1
#val2=val2
end
def add_two_numbers(v3)
return #val1+#val2+v3
end
end
So you are defining a method outside of a class (which is want we don't want)
def add_two_numbers(v3)
return #val1+#val2+v3
end
You always want to make sure that you keep your classes and you logic as two separate entities in terms of organization. By that I mean:
Your classes in one file (calc.rb):
**class Calc
attr_accessor :val1, :val2
def initialize (val1,val2)
#val1=val1
#val2=val2
end
def add_two_numbers(v3)
return #val1+#val2+v3
end
end**
And your logic to access calc.rb in another file. Use require relative to access the logic inside the class file:
require_relative"/calc.rb"
a=Calc.new(2,3)
a.add_two_numbers(3)
Tip: When I was learning ruby the best way to keep them in two separate files for better organization.That way you know you don't have a method somewhere outside of the class. This would avoid your "no method error"
I have an app that includes modules into core Classes for adding client customizations.
I'm finding that class_eval is a good way to override methods in the core Class, but sometimes I would like to avoid re-writing the entire method, and just defer to the original method.
For example, if I have a method called account_balance, it would be nice to do something like this in my module (i.e. the module that gets included into the Class):
module CustomClient
def self.included base
base.class_eval do
def account_balance
send_alert_email if balance < min
super # Then this would just defer the rest of the logic defined in the original class
end
end
end
end
But using class_eval seems to take the super method out of the lookup path.
Does anyone know how to work around this?
Thanks!
I think there are several ways to do what you're wanting to do. One is to open the class and alias the old implementation:
class MyClass
def method1
1
end
end
class MyClass
alias_method :old_method1, :method1
def method1
old_method1 + 1
end
end
MyClass.new.method1
=> 2
This is a form of monkey patching, so probably best to make use of the idiom in moderation. Also, sometimes what is wanted is a separate helper method that holds the common functionality.
EDIT: See Jörg W Mittag's answer for a more comprehensive set of options.
I'm finding that instance_eval is a good way to override methods in the core Class,
You are not overriding. You are overwriting aka monkeypatching.
but sometimes I would like to avoid re-writing the entire method, and just defer to the original method.
You can't defer to the original method. There is no original method. You overwrote it.
But using instance_eval seems to take the super method out of the lookup path.
There is no inheritance in your example. super doesn't even come into play.
See this answer for possible solutions and alternatives: When monkey patching a method, can you call the overridden method from the new implementation?
As you say, alias_method must be used carefully. Given this contrived example :
module CustomClient
...
host.class_eval do
alias :old_account_balance :account_balance
def account_balance ...
old_account_balance
end
...
class CoreClass
def old_account_balance ... defined here or in a superclass or
in another included module
def account_balance
# some new stuff ...
old_account_balance # some old stuff ...
end
include CustomClient
end
you end up with an infinite loop because, after alias, old_account_balance is a copy of account_balance, which now calls itself :
$ ruby -w t4.rb
t4.rb:21: warning: method redefined; discarding old old_account_balance
t4.rb:2: warning: previous definition of old_account_balance was here
[ output of puts removed ]
t4.rb:6: stack level too deep (SystemStackError)
[from the Pickaxe] The problem with this technique [alias_method] is that you’re relying on there not being an existing method called old_xxx. A better alternative is to make use of method objects, which are effectively anonymous.
Having said that, if you own the source code, a simple alias is good enough. But for a more general case, i'll use Jörg's Method Wrapping technique.
class CoreClass
def account_balance
puts 'CoreClass#account_balance, stuff deferred to the original method.'
end
end
module CustomClient
def self.included host
#is_defined_account_balance = host.new.respond_to? :account_balance
puts "is_defined_account_balance=#{#is_defined_account_balance}"
# pass this flag from CustomClient to host :
host.instance_variable_set(:#is_defined_account_balance,
#is_defined_account_balance)
host.class_eval do
old_account_balance = instance_method(:account_balance) if
#is_defined_account_balance
define_method(:account_balance) do |*args|
puts 'CustomClient#account_balance, additional stuff'
# like super :
old_account_balance.bind(self).call(*args) if
self.class.instance_variable_get(:#is_defined_account_balance)
end
end
end
end
class CoreClass
include CustomClient
end
print 'CoreClass.new.account_balance : '
CoreClass.new.account_balance
Output :
$ ruby -w t5.rb
is_defined_account_balance=true
CoreClass.new.account_balance : CustomClient#account_balance, additional stuff
CoreClass#account_balance, stuff deferred to the original method.
Why not a class variable ##is_defined_account_balance ? [from the Pickaxe] The module or class definition containing the include gains access to the constants, class variables, and instance methods of the module it includes.
It would avoid passing it from CustomClient to host and simplify the test :
old_account_balance if ##is_defined_account_balance # = super
But some dislike class variables as much as global variables.
[from the Pickaxe] The method Object#instance_eval lets you set self to be some arbitrary object, evaluates the code in a block with, and then resets self.
module CustomClient
def self.included base
base.instance_eval do
puts "about to def account_balance in #{self}"
def account_balance
super
end
end
end
end
class Client
include CustomClient #=> about to def account_balance in Client
end
As you can see, def account_balance is evaluated in the context of class Client, the host class which includes the module, hence account_balance becomes a singleton method (aka class method) of Client :
print 'Client.singleton_methods : '
p Client.singleton_methods #=> Client.singleton_methods : [:account_balance]
Client.new.account_balance won't work because it's not an instance method.
"I have an app that includes modules into core Classes"
As you don't give much details, I have imagined the following infrastructure :
class SuperClient
def account_balance
puts 'SuperClient#account_balance'
end
end
class Client < SuperClient
include CustomClient
end
Now replace instance_eval by class_eval. [from the Pickaxe] class_eval sets things up as if you were in the body of a class definition, so method definitions will define instance methods.
module CustomClient
...
base.class_eval do
...
print 'Client.new.account_balance : '
Client.new.account_balance
Output :
#=> from include CustomClient :
about to def account_balance in Client #=> as class Client, in the body of Client
Client.singleton_methods : []
Client.new.account_balance : SuperClient#account_balance #=> from super
"But using instance_eval seems to take the super method out of the lookup path."
super has worked. The problem was instance_eval.
I'm trying to check if a method is defined in a module using Module.method_defined?(:method) and it is returning false it should be returing true.
module Something
def self.another
1
end
end
Something.methods has 'another' listed but Something.method_defined?(:another) returns false.
Is this maybe not working because the method is defined on self? If this is the case is there another way to check if the method is defined on the module other than using method_defined??
To know whether the module has a module method, you can use respond_to?
on the
module:
Something.respond_to?(another)
=> true
method_defined? will tell you whether INSTANCES of the class with the module included responds to the given method.
Modules methods are defined in its metaclass. So you can also check for method inclusion with:
k = class << Something; self; end # Retrieves the metaclass
k.method_defined?(:another) #=> true
You can read more about it in Understanding Ruby Metaclasses.
I'm adding my version of the answer
Using the singleton_methods method:
module Something
def self.another
end
end
Something.singleton_methods.include?(:another) #=> true, with all parent modules
Something.singleton_methods(false).include?(:another) #=> true, will check only in the Something module