I know there's a dependency management system hidden behind ActiveSupport::Concern. I do not understand it completely (and I'm not sure I am ready to yet), but in a nutshell : is it possible to mix ActiveSupport::Concern with vanilla (non ActiveSupport::Concern) modules, or are there pitfalls ?
Here are some examples of the different usages I can think of
module Vanilla
module ModuleIncludedInASC
# Vanilla module
end
module ModuleIncludedInClass
# Vanilla module
end
module ASC
module ConcernIncludedInClass
extend ActiveSupport::Concern
...
end
module ConcernIncludedInASC
extend ActiveSupport::Concern
...
end
module ConcernIncludingVanillaModulesIncludedInClass
extend ActiveSupport::Concern
include Vanilla::VanillaConcernIncludedInASC
end
module ConcernIncludingASCConcernIncludedInASC
extend ActiveSupport::Concern
include ConcernIncludedInASC
end
end
class MyFoo
include Vanilla::ModuleIncludedInClass
include ASC::ConcernIncludedInClass
include ASC::ConcernIncludingVanillaModulesIncludedInClass
end
# Ans also possibly, ActiveSupport::Concern modules included in vanilla modules...?
Could that potentially lead to problems ?
It shouldn't be a problem.
I can't speak to the deep technical details, but I've never seen anyone mention it's risky, and I do this all the time. I have some models with 10+ includes. Some of those modules are using ActiveSupport::Concern, some aren't. Never encountered any issue.
I'd suggest trying it and post a new question if it does cause problems.
I haven't had any problem yet, but yes, theoretically there is a potential problem.
The methods that are defined in a normal module are appended to the method lookup chain if you include that module in a class. So the methods defined in the class will override the methods in the normal module.
The methods that are defined in a concern's included block will be added directly to the class that includes the concern.
The result is, even if you include concern earlier than a normal module, the methods in a concern will always override the methods in a normal module.
Example
module Normal
def foo
'normal'
end
end
module Concern
extend ActiveSupport::Concern
included do
def foo
'concern'
end
end
end
class Bar
include Concern # include concern first
include Normal # then include normal
end
Bar.new.foo #=> "concern"
Maybe you would expect "normal" to be returned, but that's never gonna happen.
Related
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/
Given the following:
class User; attr_accessor :roles; end
module RegisteredUser
def default_context
Submission
end
end
module Admin
def default_context
Review
end
end
current_user = User.new
current_user.roles = ["registered_user", "admin"]
current_user.roles.each do |role|
role_module = role.gsub(/ /, '_').camelize
if module_exists?(role_module)
current_user.extend role_module.constantize
end
end
context = self.extend current_user.default_context
Is there a way to set the priority of User#default_context? That is, can I say that the Admin#default_context always takes priority over RegisteredUser#default_context regardless of the order in which current_user is extended?
method_added is in Module.
I actually meant included, not extended, but both are also in Module.
The mechanism would revolve around doing something like this:
module Foo
def self.included(base)
base.extend(FooMethods)
end
module FooMethods
def bar
# Whatever
end
end
end
Inside Foo.included you can determine, based on arbitrary criteria, whether or not the methods in question should be added to base (the entity including the module).
In your case, you could check to see if a "higher priority" module was already included, or see if the module is the "higher priority" module. Based on that you'd decide whether or not to add the methods.
Since an Admin is also a RegisteredUser, I would do
module Admin
include RegisteredUser
...
end
and then only
current_user.extend Admin
I am not sure if this is the correct way. If Admin and RegisteredUser were classes, it would make sense making Admin inherit from RegisteredUser. In case of modules, dunno.
You cannot; in Ruby the order of module inclusion is the order in which modules are searched (after the current class, before parent classes). The only way to change the 'priority' is to include the modules in the order you want, or to move them to a parent class.
Although not pure Ruby, you can use the Remix library by banisterfiend to change module ordering (or unmixin a module, or...other things).
I encountered a problem when trying to test a module with Test::Unit. What I used to do is this:
my_module.rb:
class MyModule
def my_func
5 # return some value
end
end
test_my_module.rb:
require 'test/unit'
require 'my_module'
class TestMyModule < Unit::Test::TestCase
include MyModule
def test_my_func
assert_equal(5, my_func) # test the output value given the input params
end
end
Now the problem is, if my_module declares an initialize method, it gets included in the test class and this causes a bunch of problems since Test::Unit seems to override/generate an initialize method. So I'm wondering what is the best way to test a module?
I'm also wondering wether my module should become a class at this point since the initialize method is made for initializing the state of something. Opinions?
Thanks in advance !
Including an initialize method in a module feels very wrong to me, so I'd rethink that at the very least.
To answer your question about testing this as a module more directly, though, I would create a new, empty class, include your module in it, create an instance of that class, and then test against that instance:
class TestClass
include MyModule
end
class TestMyModule < Unit::Test::TestCase
def setup
#instance = TestClass.new
end
def test_my_func
assert_equal(5, #instance.my_func) # test the output value given the input params
end
end
Yeah, your initialize should definitely suggest that you're going towards a class. A module in ruby often feels like an interface in other languages, as long as you implement some basic things when you include the module you'll get a lot for free.
Enumerable is a great example, as long as you define [] and each when you include Enumerable you suddenly get pop, push, etc.
So my gut feeling about testing modules is that you should probably be testing classes that include the module rather than testing the module itself unless the module is designed to not be included in anything, it's simply a code storage mechanism.
It seems a lot of libraries/plugins use this syntax:
def self.included(base) # :nodoc:
base.extend ClassMethods
end
Why is the :nodoc: part necessary?
It is not necessary. If applied to a class, it just suppresses documentation (rdoc) for all the methods in the Class extension. Described in Programming Ruby as:
:nodoc: -
Don't include this element in
the documentation. For classes and
modules, the methods, aliases,
constants, and attributes directly
within the affected class or module
will also be omitted from the
documentation. By default, though,
modules and classes within that class
or module will be documented.
I don't think it's necessary. Actually, in my opinion, it's one of the most useless features of RDoc.
So many times I've seen it while reading a libarie's code and I had to ask myself "Why?". I don't see any reason to use this feature. If you don't want people to use your method, just make it private. It's a big hassle when reading documentation and seeing a method call to a method that's left out of the documentation.
In Ruby, since you can include multiple mixins but only extend one class, it seems like mixins would be preferred over inheritance.
My question: if you're writing code which must be extended/included to be useful, why would you ever make it a class? Or put another way, why wouldn't you always make it a module?
I can only think of one reason why you'd want a class, and that is if you need to instantiate the class. In the case of ActiveRecord::Base, however, you never instantiate it directly. So shouldn't it have been a module instead?
I just read about this topic in The Well-Grounded Rubyist (great book, by the way). The author does a better job of explaining than I would so I'll quote him:
No single rule or formula always results in the right design. But it’s useful to keep a
couple of considerations in mind when you’re making class-versus-module decisions:
Modules don’t have instances. It follows that entities or things are generally best
modeled in classes, and characteristics or properties of entities or things are
best encapsulated in modules. Correspondingly, as noted in section 4.1.1, class
names tend to be nouns, whereas module names are often adjectives (Stack
versus Stacklike).
A class can have only one superclass, but it can mix in as many modules as it wants. If
you’re using inheritance, give priority to creating a sensible superclass/subclass
relationship. Don’t use up a class’s one and only superclass relationship to
endow the class with what might turn out to be just one of several sets of characteristics.
Summing up these rules in one example, here is what you should not do:
module Vehicle
...
class SelfPropelling
...
class Truck < SelfPropelling
include Vehicle
...
Rather, you should do this:
module SelfPropelling
...
class Vehicle
include SelfPropelling
...
class Truck < Vehicle
...
The second version models the entities and properties much more neatly. Truck
descends from Vehicle (which makes sense), whereas SelfPropelling is a characteristic of vehicles (at least, all those we care about in this model of the world)—a characteristic that is passed on to trucks by virtue of Truck being a descendant, or specialized
form, of Vehicle.
I think mixins are a great idea, but there's another problem here that nobody has mentioned: namespace collisions. Consider:
module A
HELLO = "hi"
def sayhi
puts HELLO
end
end
module B
HELLO = "you stink"
def sayhi
puts HELLO
end
end
class C
include A
include B
end
c = C.new
c.sayhi
Which one wins? In Ruby, it turns out the be the latter, module B, because you included it after module A. Now, it's easy to avoid this problem: make sure all of module A and module B's constants and methods are in unlikely namespaces. The problem is that the compiler doesn't warn you at all when collisions happen.
I argue that this behavior does not scale to large teams of programmers-- you shouldn't assume that the person implementing class C knows about every name in scope. Ruby will even let you override a constant or method of a different type. I'm not sure that could ever be considered correct behavior.
My take: Modules are for sharing behavior, while classes are for modeling relationships between objects. You technically could just make everything an instance of Object and mix in whatever modules you want to get the desired set of behaviors, but that would be a poor, haphazard and rather unreadable design.
The answer to your question is largely contextual. Distilling pubb's observation, the choice is primarily driven by the domain under consideration.
And yes, ActiveRecord should have been included rather than extended by a subclass. Another ORM - datamapper - precisely achieves that!
I like Andy Gaskell's answer very much - just wanted to add that yes, ActiveRecord should not use inheritance, but rather include a module to add the behavior (mostly persistence) to a model/class. ActiveRecord is simply using the wrong paradigm.
For the same reason, I very much like MongoId over MongoMapper, because it leaves the developer the chance to use inheritance as a way of modelling something meaningful in the problem domain.
It's sad that pretty much nobody in the Rails community is using "Ruby inheritance" the way it's supposed to be used - to define class hierarchies, not just to add behavior.
The best way I understand mixins are as virtual classes. Mixins are "virtual classes" that have been injected in a class's or module's ancestor chain.
When we use "include" and pass it a module, it adds the module to the ancestor chain right before the class that we are inheriting from:
class Parent
end
module M
end
class Child < Parent
include M
end
Child.ancestors
=> [Child, M, Parent, Object ...
Every object in Ruby also has a singleton class. Methods added to this singleton class can be directly called on the object and so they act as "class" methods. When we use "extend" on an object and pass the object a module, we are adding the methods of the module to the singleton class of the object:
module M
def m
puts 'm'
end
end
class Test
end
Test.extend M
Test.m
We can access the singleton class with the singleton_class method:
Test.singleton_class.ancestors
=> [#<Class:Test>, M, #<Class:Object>, ...
Ruby provides some hooks for modules when they are being mixed into classes/modules. included is a hook method provided by Ruby which gets called whenever you include a module in some module or class. Just like included, there is an associated extended hook for extend. It will be called when a module is extended by another module or class.
module M
def self.included(target)
puts "included into #{target}"
end
def self.extended(target)
puts "extended into #{target}"
end
end
class MyClass
include M
end
class MyClass2
extend M
end
This creates an interesting pattern that developers could use:
module M
def self.included(target)
target.send(:include, InstanceMethods)
target.extend ClassMethods
target.class_eval do
a_class_method
end
end
module InstanceMethods
def an_instance_method
end
end
module ClassMethods
def a_class_method
puts "a_class_method called"
end
end
end
class MyClass
include M
# a_class_method called
end
As you can see, this single module is adding instance methods, "class" methods, and acting directly on the target class (calling a_class_method() in this case).
ActiveSupport::Concern encapsulates this pattern. Here's the same module rewritten to use ActiveSupport::Concern:
module M
extend ActiveSupport::Concern
included do
a_class_method
end
def an_instance_method
end
module ClassMethods
def a_class_method
puts "a_class_method called"
end
end
end
Right now, I'm thinking about the template design pattern. It just wouldn't feel right with a module.