Why given a module like this:
module TestModule
module Configuration
# Return the configuration values set in this module
def options
puts "OPTIONS IS IN"
puts self.inspect
end
end
end
I get that the options method is in TestModule and not in Configuration?
EDIT: I add the gem that I am taking a look at, and the one that has given me this confusion:
Check this file: configuration.rb in line 37 the method options is defined.
In the class Client however, when options is called (line 11) is used doing Awesome instead of Configuration. Why is that? I don't see any class named Awesome where those modules are being mixed.
The gem in question does (in awesome.rb)
module Awesome
extend Configuration
end
So all of the methods on Awesome::Configuration (such as options) become singleton methods on the Awesome module
Technically, it's not part of either. It would have to be mixed in to a class to make it part of a class. To make it callable directly on the module, you need to prefix it with self. in the definition to make it a module method instead of an instance method:
def self.options
self #=> TestModule::Configuration
end
Here's a good tutorial on mixins which allows you to use the instance methods: http://rubylearning.com/satishtalim/modules_mixins.html
Related
I've got some kind of template patterned module with few method defined (default behaviour) and some which look like method below:
def tax
1.2
end
def do_something!
raise "Please implement it in your class"
end
I've read that in most cases I should use modules over inheritance because of inheritance capabilities (single inheritance) and when I don't need super() at all.
But I feel a bit guilty to override all raise "..." methods and also some default (like tax method), because it is module.
What do you think?
When I need to override methods should I rather use inheritance or including modules?
The rule I usually follow is: when the method has to be defined in the class including the module (e.g. module acts as an interface) i always do:
def method_that_needs_to_be_defined
raise NoMethodError
end
It's good practice, prevents unexpected calls to yet undefined method.
Example:
module Speaker
def speak
raise NoMethodError
end
end
class Bird < Animal
include Speaker
def speak
'chirp'
end
end
I am working in live project and understanding the existing code.
like
Module Rating
def current_rating
# some code here
end
end
And called this method in included class.
How it works?
Actually I know about module but not used much. Say I am beginner for Module
module_function
Module methods that are declared as module_function will create copies of themselves as private instance methods in the class that includes the Module:
check this link: Hidden features of Ruby
I am reading this explanation of module methods for Ruby and how they are different from instance methods for classes. Here is the explanation I am reading:
Remember that unlike an instance method, a module method needs to be
defined on the module itself. How do you access the module? Recall
that inside a module definition, self refers to the module being
defined. So you'll need to define the method using the form self.xxx.
I don't totally get it. When we defined methods inside Classes, we didn't have to define it on the class itself. We merely called it on the instantiated objects of the classes.
Why do we need to define module methods on the module itself using the term "self"? What's the purpose of this? Why can't we just define module methods without using the term self? Here is how my module skeleton looks:
module GameTurn
def self.take_turn(player)
end
There's two kinds of module methods:
Those that are intended to be mixed in to other modules or classes: "Mixins"
Those that are intended to be used directly: "Exposed Methods"
For example:
module Example
def self.exposed_method
# This method is called as Example.exposed_Method
end
def mixin_method
# This method must be imported somewhere else with include or extend
# or it cannot be used.
end
end
You have two on a class as well:
Those that are called only on instances of the class: "Instance methods"
Those that are called directly on the class: "Class methods"
These are also called "static methods" in other languages.
Example:
class ExampleClass
def self.class_method
# This can be called as ExampleClass.class_method
end
def instance_method
# This can only be called on an instance: ExampleClass.new.instance_method
end
end
module A
end
class Klass
include A
end
How does this include influence Klass? Does it simply put Klass into module A or do something more?
Short Answer: If you have some methods inside your module and you use include in a class, those methods can be used in the class.
Module A
def shout
puts "HEY THERE!!!!"
end
end
class Klass
include A
end
# Create instance of Klass
instance = Klass.new
# Produces "HEY THERE!!!!"
instance.shout
The include method takes all the methods from another module and
includes them into the current module. This is a language-level thing
as opposed to a file-level thing as with require. The include method
is the primary way to "extend" classes with other modules (usually
referred to as mix-ins). For example, if your class defines the method
"each", you can include the mixin module Enumerable and it can act as
a collection. This can be confusing as the include verb is used very
differently in other languages.
from here: What is the difference between include and require in Ruby?
also take a look at this page: http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html it has a verbose explanation about how include works.
include is one of the ways to include methods of a Module in another Module or Class.
Please read my article on how that affects method calls in Ruby/
It looks like const_missing is an instance method of Object. If so, why doesn't this code work?
module Extensions
def const_missing(c)
puts c
end
end
class Object
include Extensions
end
NonExistent.new
In order to get it to function correctly, I have to change def const_missing to def Object.const_missing. Why?
This is just a consequence of the way method calls are resolved in Ruby.
First, singleton methods are checked. Then instance methods of the class, followed by the ancestors (which will be the included modules, then superclasses with their included modules).
So you could define Object.const_missing directly, or include your Module in the singleton class of Object:
class << Object
include Extensions
end
NonExistent # => prints "NonExistent"
You could also monkeypatch Module#const_missing.