How does this ruby "method" work? - ruby

I am working with Sinatra but I am completely new to Ruby and confused about what the below code is actually doing.
class Something < Sinatra::Base
get '/' do
'hello world'
end
end
We don't seem to be defining a method. Are we calling the get method? If so, at what time is it called? I've not seen anything like this in other languages.
If we had 2 classes that extended Sinatra::Base how would Sinatra understand that the get applies to Something rather than the other class.

As opposed to the way, e.g., Java functions, when you define classes in Ruby, Ruby is actually executing code. Kind of like Java's static blocks. So when you do e.g.
class Foo
puts(self)
end
you will open a class (i.e. change the current self to Foo), within its context do a puts (which will print out the Foo class object), and then close the class (returning self to what it was before).
get is a method defined on Sinatra::Base. Thus, your code is actually interpreted as if it were
class Something < Sinatra::Base
self.get('/') do
'hello world'
end
end
Because self (i.e. Foo) inherits from Sinatra::Base, that's a method we're invoking - and we're doing it as the Something class definition is being read.
What that method does, roughly, is keep a table of "things to do when GET request comes in". It remembers that when it sees URL /, it should do the block do "hello world" end; more-or-less like this (example code; the original is a bit more complex):
class Sinatra::Base
WHAT_TO_DO_ON_GET = {}
def self.get(url, &thing_to_do)
WHAT_TO_DO_ON_GET[url] = thing_to_do
end
end
The Sinatra runtime is just a loop that, when a GET request comes in, looks up the URL against THINGS_TO_DO_ON_GET and executes what it finds there.

Related

What is the scope of variables and methods included via ruby modules?

Suppose I have the following:
module MyModule
module SubModule
Var = 'this is a constant'
var = 'this is not a constant'
def hello_world
return 'hello world!'
end
end
end
In the same file, I can only seem to access MyModule::SubModule::Var, but not any the constant or the method. If I now create a class and include these modules in different ways, I get additional strange behavior:
class MyClass
include MyModule
def initialize()
puts SubModule::Var
end
def self.cool_method
puts SubModule::Var
end
end
In this case, I can again only access Var, but not the other two. SubModule::var and SubModule::hello_world do not work. Finally:
class MyClass
include MyModule::SubModule
def initialize()
puts Var
puts hello_world
end
def self.cool_method
puts Var
puts hello_world
end
end
In this case, I can now access both Var and the method hello_world but not var, and, the weirdest thing, is that hello_world appears to have become an instance method! That is, the call to hello_world in initialize works, but the one in self.cool_method doesn't. This is pretty strange, considering that Var seems to have been included as a class variable, since outside the class, I must access them like so:
MyClass::Var
x = MyClass.new
x.hello_world
So, I have a few major questions.
What is going on behind the scenes with regards to Var vs var? It appears that capitalizing a variable name is more than just a convention after all.
When includeing a module, what kinds of things are passed to the including class, and at what scope?
Is there a way to do the opposite? That is, use include to include an instance variable or a class method?
What is going on behind the scenes with regards to Var vs var? It appears that capitalizing a variable name is more than just a convention after all.
Yes, of course, it's not a convention. Variables which start with an uppercase letter are constants, variables which start with a lowercase letter are local variables. The two are completely different.
When includeing a module, what kinds of things are passed to the including class, and at what scope?
Nothing gets passed anywhere. includeing a mixin simply makes that mixin the superclass of the class you are includeing it into. That's all. Everything else then works exactly as with classes.
Is there a way to do the opposite? That is, use include to include an instance variable or a class method?
I don't understand this question. Instance variables have nothing to do with mixins or classes. They belong to instances, that's why they are called "instance" variables.
There are no such things as "class methods" in Ruby. Ruby only knows one kind of methods: instance methods. When Rubyists talk to each other, they will sometimes use the term "class method" to mean "singleton method of an object that happens to be a class", but they do that knowing full well that class methods don't actually exist, it's just a shorthand in conversation. (And, of course, singleton methods don't exist either, they are just a convenient way of saying "instance method of the singleton class".)

Use application class instance variable inside get block

I am using sinatra and I have the code:
class App < Sinatra::Base
configure do
#logger = Logger.new "./log"
end
#logger.info "App started" #this line works
get "/info" do
#logger.info "/info inquired" #this does not work and complain #logger is nilClass
end
end
Why #logger inside get block gives a nil object? How can I use #logger in this case?
PS. If I use a class variable like ##logger, the code above works. But why the instance variable is not working in this case?
Instance variables attach themselves to whatever object is self at the time the instance variables spring into existence.
On the face of things, these are the values for self:
class App < Sinatra::Base
#In here, self=App
#When a block executes, it sees the value for self that existed in
#the surrounding scope at the time the block was CREATED:
configure do #a block
#So...in here self=App
#logger = Logger.new "./log"
end
#logger.info "App started" #this line works
get "/info" do #a block
#Similarly, in here self=App
#logger.info "/info inquired" ##logger is NilClass
end
end
Based on that state of things, you are right to be confused: it looks like when configure() executes the block that is passed to it, #logger will spring into existence and attach itself to App, then when get() calls the block that is passed to it, the #logger instance variable will refer to the instance variable attached to App.
But...ruby offers ways to change the value of self that a block sees when the block EXECUTES. Here is an example:
p = Proc.new { puts self }
p.call
class Dog
def initialize(a_proc)
#In here, self is a Dog instance
instance_eval &a_proc
end
end
Dog.new p
--output:--
main
#<Dog:0x000001009b6080>
Based on your error, you have to suspect that Sinatra must be employing some ruby tricks to change self when it executes the block passed to get().
How can we know this?
Ruby is the wild west of programming languages, so you can't ever know what is going to happen unless you look at the source code or good docs if they exist. The source code is pretty convoluted. I found this in the docs:
Some knowledge of Sinatra’s internal design is required to write good
extensions. This section provides a high level overview of the classes
and idioms at the core of Sinatra’s design.
Sinatra has two distinct modes of use that extensions should be aware
of:
The “Classic” style, where applications are defined on main / the
top-level – most of the examples and documentation target this usage.
Classic applications are often single-file, standalone apps that are
run directly from the command line or with a minimal rackup file. When
an extension is required in a classic application, the expectation is
that all extension functionality should be present without additional
setup on the application developers part (like included/extending
modules).
The “Modular” style, where Sinatra::Base is subclassed explicitly and
the application is defined within the subclass’s scope. These
applications are often bundled as libraries and used as components
within a larger Rack-based system. Modular applications must include
any desired extensions explicitly by calling register ExtensionModule
within the application’s class scope.
Most extensions are relevant to both styles but care must be taken by
extension authors to ensure that extensions do the right thing under
each style. The extension API (Sinatra.register and Sinatra.helpers)
is provided to help extension authors with this task.
Important: The following notes on Sinatra::Base and
Sinatra::Application are provided for background only - extension
authors should not need to modify these classes directly.
Sinatra::Base The Sinatra::Base class provides the context for all
evaluation in a Sinatra application. The top-level DSLish stuff exists
in class scope while request-level stuff exists at instance scope.
Applications are defined within the class scope of a Sinatra::Base
subclass. The “DSL” (e.g., get, post, before, configure, set, etc.) is
simply a set of class methods defined on Sinatra::Base. Extending the
DSL is achieved by adding class methods to Sinatra::Base or one of its
subclasses. However, Base classes should not be extended with extend;
the Sinatra.register method (described below) is provided for this
task.
Requests are evaluated within a new Sinatra::Base instance – routes,
before filters, views, helpers, and error pages all share this same
context. The default set of request-level helper methods (e.g, erb,
haml, halt, content_type, etc.) are simple instance methods defined on
Sinatra::Base or within modules that are included in Sinatra::Base.
Providing new functionality at the request level is achieved by adding
instance methods to Sinatra::Base.
As with DSL extensions, helper modules should not be added directly to
Sinatra::Base by extension authors with include; the Sinatra.helpers
method (described below) is provided for this task.
http://www.sinatrarb.com/extensions.html
You can define your own logger in your Sinatra::Base and use it in your get block by doing:
class App < Sinatra::Base
set :logger, Logger.new("./log")
helpers do
def logger; self.class.logger; end
end
logger.info self
get "/info" do
logger.info self
end
# ...
end
Or by using the class variable as you note in your edit. The log file from the above configuration shows why:
I, [2014-06-01T16:36:51.593033 #16144] INFO -- : App
I, [2014-06-01T16:36:59.438078 #16144] INFO -- : #<App:0x9aa919c #default_layout=:layout, #app=nil ...
In the first case, self is the application class, while in the get block, self is the instance of the class.
To clarify, in your example: Ruby interprets the first #logger.info (called from the context of your class) to be a class instance variable, while the second #logger.info is interpreted as an instance variable (which has not been defined). The variable you define in your configure block is set in the class context.

How can I mock super in ruby using rspec?

I am extending an existing library by creating a child class which extends to the library class.
In the child class, I was able to test most of functionality in initialize method, but was not able to mock super call. The child class looks like something like below.
class Child < SomeLibrary
def initialize(arg)
validate_arg(arg)
do_something
super(arg)
end
def validate_arg(arg)
# do the validation
end
def do_something
#setup = true
end
end
How can I write rspec test (with mocha) such that I can mock super call? Note that I am testing functionality of initialize method in the Child class. Do I have to create separate code path which does not call super when it is provided with extra argument?
You can't mock super, and you shouldn't. When you mock something, you are verifying that a particular message is received, and super is not a message -- it's a keyword.
Instead, figure out what behavior of this class will change if the super call is missing, and write an example that exercises and verifies that behavior.
As #myron suggested you probably want to test the behavior happening in super.
But if you really want to do this, you could do:
expect_any_instance_of(A).to receive(:instance_method).and_call_original
Assuming
class B < A
def instance_method
super
end
end
class A
def instance_method
#
end
end
Disclaimer expect_any_instance_of are a mark of weak test (see):
This feature is sometimes useful when working with legacy code, though
in general we discourage its use for a number of reasons:
The rspec-mocks API is designed for individual object instances, but
this feature operates on entire classes of objects. As a result there
are some semantically confusing edge cases. For example, in
expect_any_instance_of(Widget).to receive(:name).twice it isn't clear
whether a specific instance is expected to receive name twice, or if
two receives total are expected. (It's the former.)
Using this feature is often a design smell. It may be that your test is trying to do too much or that the object under test is too
complex.
It is the most complicated feature of rspec-mocks, and has historically received the most bug reports. (None of the core team
actively use it, which doesn't help.)
A good way to test this is to set an expectation of some action taken by the superclass - example :
class Some::Thing < Some
def instance_method
super
end
end
and the super class:
class Some
def instance_method
another_method
end
def self.another_method # not private!
'does a thing'
end
end
now test :
describe '#instance_method' do
it 'appropriately triggers the super class method' do
sawm = Some::Thing.new
expect(sawm).to receive(:another_method)
sawm.instance_method
end
end
All This Determines Is That Super Was Called On the Superclass
This pattern's usefulness is dependent on how you structure your tests/what expectations you have of the child/derivative class' mutation by way of the super method being applied.
Also - pay close attention to class and instance methods, you will need to adjust allows and expects accordingly
YMMV
A bit late to this party, but what you can also do is forego using the super keyword and instead do
class Parent
def m(*args)
end
end
class Child < Parent
alias super_m m
def m(*args)
super_m(*args)
end
end
That way your super method is accessible like any other method and can e.g. be stubbed like any other method. The main downside is that you have to explicitly pass arguments to the call to the super method.

How to Intercept Class Definitions in Ruby?

Is it possible to code something that can tell me when a Ruby class is defined?
Yes!
class Object
def self.inherited(base)
puts "#{base} inherited from object"
end
end
class Animal
end
class Cat < Animal
end
Running the above code prints the following:
Animal inherited from object
Cat inherited from object
Basically, the self.inherited callback is triggered whenever a class is defined that inherits from the class it is defined on. Put it on Object and that's any class! (Although there may be some special case exceptions I can't think of just now).
I should probably add the disclaimer that, while it is possible to do this (because of just how awesome Ruby is as a language), whether it is advisable to do this, especially in code destined for production use, I'm not so sure. Well, actually, I am sure. It would be a bad idea.

Ruby: calling methods on init

I switched to Ruby from PHP, and have yet to understand a curious Ruby class behavior where methods are executed outside of the class method definitions (see example below). In PHP, when we wanted to execute anything on class init, we would put it in the constructor method.
Ruby example (Rails):
class Comment < ActiveRecord::Base
belongs_to :post, :counter_cache => true
end
Am I correct in understanding that belongs_to will be executed on instantiation? And is belongs_to a class method inherited from ActiveRecord?
Thanks!
In Ruby, everything is executable code. Or, to put it another way: everything is a script. There is no such thing as a "class declaration" or something like that.
Any code that sits in a file, without being inside anything else like a method body, a class body, a module body or a block body, is executed when that file is loaded (or required or require_relatived). This is called a script body.
Any code that sits inside a class or module body is executed when that class or module is created. (This is the case you are referring to.)
The boring part: any code that sits inside a method body is executed when that method is called, or more precisely, when that method is invoked in response to receiving a message with the same name as the method. (Duh.)
Any code that sits inside a block body is executed when that block is yielded to.
Since a class definition is just a script, this means that it can contain any sort of code you want, including method calls:
class Foo
attr_accessor :bar # Yes, attr_accessor is just a method like any other
private # I *bet* you didn't know *that* was a method, too, did you?
end
or conditionals:
class Bar
if blah # e.g. check if the OS is Windows
def foo
# one way
end
else
def foo
# a different way
end
end
end
Yes, it's a class method from ActiveRecord. The method will execute when the class itself is created, not when an instance of it is created.
Yes, that's correct. See also this question.

Resources