In Ruby, classes are never closed: you can always add methods to an
existing class. This applies to the classes you write as well as the
standard, built-in classes. All you have to do is open up a class
definition for an existing class, and the new contents you specify
will be added to whatever's there. In the same regard, if module is
used with the name of a pre-existing module that module is re-opened.
If a method is defined in a re-opened module with the same name as a
pre-existing method in the same module the old method is overwritten
with the new. And, of course, modules can be made immutable,
effectively preventing them from being reopened by freezing the module
object. Frozen modules raise RuntimeErrors when methods are defined,
or variables manipulated, in their context.
When you include a module in a class, without a prefix (prefix meaning
something like this: AbstractController::Layouts), then ruby searches
for the module of that name within the scope of the current module
wrapping the class that the include was called in.
So, for example:
module ActionController
class Base
include Rendering
Since we "include Rendering" within the scope of the Base class
object, ruby first looksup the constant Rendering, that is, looking
for a module named Rendering in the ActionController namespace, since
that is the namesapce that Base is defined in???
Well, ActionController module does define a module named Rendering:
module ActionController
module Rendering
def render(*args)
raise ::AbstractController::DoubleRenderError if response_body
super
self.content_type ||= Mime[lookup_context.rendered_format].to_s
response_body
end
So now the method render(*args) is included in the Base class as an
instance method. So when we call, for example, (hypothetically)
ActionView::Base.new.render :action => "my_action", :layout => false,
ActionView::Base is instantiated and we invoke the render instance
method, and since no render method is declared in the Base class
context, ruby scope chain does lookup into the module Rendering and
finds the method so calls it. Now, as you may know, it's possible to
pass multiple kinds of arguments to render, depending on whether you
want to render a template or a partial or file, etc. The * syntax does
the job here, allowing you vary the number of arguments passed. It
checks if there is already a response to the request, and raises an
Exception, if so. Otherwise, it calls super.
During this super call, I got a little confused. In
ActionController::Base, there is another module included called
AbstractController::Layouts. Layouts in turn includes a module called
Rendering. Since there is a Rendering module within the
AbstractController namespace, it is found, and it indeed contains a
method called render.
def render(*args, &block)
options = _normalize_render(*args, &block)
self.response_body = render_to_body(options)
end
And because render is included in Layouts, it's included as an
instance method, and because Layouts was included in
ActionController::Base, that render method utlimately makes its way up
to the Base class. Now we have two modules
(ActionController::Rendering and AbstractController::Rendering that
are including this method into Base. So why doesn't one of them get
overwritten? Why does the call to super work?
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
