I have a Project model and a Developer model. I have the concept of calculating the "interestingness" for a project for a particular developer:
class Project < ActiveRecord::Base
def interestingness_for(developer)
some_integer_based_on_some_calculations
end
end
I think it would be neat, instead of having something like Project.order_by_interestingness_for(bill), to be able to say
Project.order(:interestingness, :developer => bill)
and have it be a scope as opposed to just a function, so I can do stuff like
Project.order(:interestingness, :developer => bill).limit(10)
I don't know how to do this, though, because it's not obvious to me how to override a scope. Any advice?
Assuming you will not need to use the standard ActiveRecord order query method for the Project class, you can override it like any other class method:
def self.order(type, options)
self.send(:"special_#{type}_calculation_via_scopes", options)
end
Then the trick is to ensure you create the needed calculation methods (which will vary according to your interestingness and other algorithms). And that the calculation methods only use scopes or other AR query interface methods. If you aren't comfortable converting the method logic to a SQL equivalent using the query interface, you can try using the Squeel DSL gem which can potentially work with the method directly depending on your specific calculation.
If you may be needing the classic order method (and this is usually a safe assumption), then don't override it. Either create a proxy non-ActiveRecord object for this purpose, or use a different naming convention.
If you really want to, you can use aliasing to achieve a similar effect, but it may have unintended consequences for the long term if the second argument ('options' in this case) suddenly takes on another meaning as Rails progresses. Here is an example of what you can use:
def self.order_with_options(type, options = nil)
if options.nil?
order_without_options(type)
else
self.send(:"special_#{type}_calculation_via_scopes", options)
end
end
class << self
alias_method_chain :order, :options
end
Related
Most of the Factorybot factories are like:
FactoryBot.define do
factory :product do
association :shop
title { 'Green t-shirt' }
price { 10.10 }
end
end
It seems that inside the ":product" block we are building a data structure, but it's not the typical hashmap, the "keys" are not declared through symbols and commas aren't used.
So my question is: what kind of data structure is this? and how it works?
How declaring "association" inside the block doesn't trigger a:
NameError: undefined local variable or method `association'
when this would happen on many other situations. Is there a subject in compsci related to this?
The block is not a data structure, it's code. association and friends are all method calls, probably being intercepted by method_missing. Here's an example using that same technique to build a regular hash:
class BlockHash < Hash
def method_missing(key, value=nil)
if value.nil?
return self[key]
else
self[key] = value
end
end
def initialize(&block)
self.instance_eval(&block)
end
end
With which you can do this:
h = BlockHash.new do
foo 'bar'
baz :zoo
end
h
#=> {:foo=>"bar", :baz=>:zoo}
h.foo
#=> "bar"
h.baz
#=> :zoo
I have not worked with FactoryBot so I'm going to make some assumptions based on other libraries I've worked with. Milage may vary.
The basics:
FactoryBot is a class (Obviously)
define is a static method in FactoryBot (I'm going to assume I still haven't lost you ;) ).
Define takes a block which is pretty standard stuff in ruby.
But here's where things get interesting.
Typically when a block is executed it has a closure relative to where it was declared. This can be changed in most languages but ruby makes it super easy. instance_eval(block) will do the trick. That means you can have access to methods in the block that weren't available outside the block.
factory on line 2 is just such a method. You didn't declare it, but the block it's running in isn't being executed with a standard scope. Instead your block is being immediately passed to FactoryBot which passes it to a inner class named DSL which instance_evals the block so its own factory method will be run.
line 3-5 don't work that way since you can have an arbitrary name there.
ruby has several ways to handle missing methods but the most straightforward is method_missing. method_missing is an overridable hook that any class can define that tells ruby what to do when somebody calls a method that doesn't exist.
Here it's checking to see if it can parse the name as an attribute name and use the parameters or block to define an attribute or declare an association. It sounds more complicated than it is. Typically in this situation I would use define_method, define_singleton_method, instance_variable_set etc... to dynamically create and control the underlying classes.
I hope that helps. You don't need to know this to use the library the developers made a domain specific language so people wouldn't have to think about this stuff, but stay curious and keep growing.
I have a Rails model, which is using the str_enum gem.
I'm building a generator which reads the models and creates pages for them, and so I'd like to be able to understand what str_enums are attached to a model.
For example
class User < ApplicationRecord
str_enum :email_frequency, %i[every daily weekly], default: 'every'
end
Ideally, I'd like to be able to query the User model and understand there is a str_enum attached to email_frequency, with values of every, daily & weekly.
Once I can understand there is a str_enum attached to a given field, I can pluralize the field and get the values:
irb(main):004:0> User.email_frequencies
=> ["every", "daily", "weekly"]
The question has also be asked over here and the suggestion is to use Module#prepend. I'm familiar with prepend to conditionally insert methods into a model.
How can I use it for this problem?
EDIT
This is quite simple with validations, for example: get validations from model
If I understand your question correctly is that you wanna get all column that has attached with enum string. If so you can override the gem method like this
# lib/extenstions/str_enum.rb
module Extensions
module StrEnum
module ClassMethods
def str_enum(column, *args)
self.str_enums << column.to_s.pluralize
super
end
end
def self.prepended(base)
class << base
mattr_accessor :str_enums
self.str_enums = []
prepend ClassMethods
end
end
end
end
In the User model
prepend Extensions::StrEnum
Now you can use
User.str_enums
to list all columns has attached with str enum.
Make sure you have add lib directory into load path.
So for starters, you could, of course, use the approach that Ninh Le has described and monkeypatch your desired behavior into the gem. In fact, I'm fairly confident that it would work, since your use case is currently relatively easy and you really just need to keep track of all the times the str_enum method gets called.
I would, however, encourage you to consider doing one of two things:
If you plan to do more complex stuff with your enums, consider using one of the more heavy-duty enum gems like enumerize, enumerate_it or active_enum. All of these are packages that have been around for a decade (give or take) and still receive support and all of them have been built with a certain degree of extensibility and introspection in mind (albeit with different approaches).
Have a look at the gem and consider building your own little macro on top of it. IMO one of multiple of Andrew Kane's libraries' biggest weaknesses is arguably their kind of hacky/scripty approach which, while making the libraries hard to extend, makes them inherently easy to understand and thus use as a basis for your own stuff (whereas the gems with a better/more elaborate approach are harder to understand and adapt beyond the means the author has intended to).
Either way, you'll be fine with both of my suggestions as well as Ninh Le's.
I'm setting up rules how to write minitests, and I want to prevent other programmers to override methods for existing classes, because it will affect other tests, where this class will be used. Here is some clarifications below.
For example, I have a class in the lib folder, KlassExample. It has a public method do_something with own logic. In minitest someone could want to override this method with other logic. I want to not allow run test, if the class logic was overridden.
Code samples:
lib/klass_example.rb
class KlassExample
def do_something
false
end
end
test/unit/lib/klass_example_test.rb
require 'unit/test_helper'
require 'klass_example'
class KlassExample
def do_something
true
end
end
class KlassExampleTest < Minitest::Test
def test_do_something
assert_equal true, KlassExample.new.do_something
end
end
I want that programmers would use MiniTest::Mock instead of class overriding, so I need some coercive actions to get them to write code in the right way.
Is there any possible complex solution how to do it?
While this particular use case might be somewhat covered with TracePoint#new(:class) by setting a TracePoint on the class re-opening and e.g. raising from there, you would never prevent all the possibilities explicitly and implicitly built into Ruby to indeed allow developers to do whatever they want.
Overwritten Module#prepended callback would disallow others to prepend modules to your class:
KlassExample.prepend(Module.new { def self.prepended(*); raise end })
There are ways to prevent Module#define_method calls, also they are already looking like hacks.
But the whole set of possibilities to fool your guard in nearly infinite, so I doubt it’s doable in general. I bet every time you would think “ok, now everything is covered,” I’d easily invent another cumbersome way to bypass all your guards.
Ruby is not the language designed to prevent developers from doing whatever they want.
Some open source code I'm integrating in my application has some classes that include code to that effect:
class SomeClass < SomeParentClass
def self.new(options = {})
super().tap { |o|
# do something with `o` according to `options`
}
end
def initialize(options = {})
# initialize some data according to `options`
end
end
As far as I understand, both self.new and initialize do the same thing - the latter one "during construction" and the former one "after construction", and it looks to me like a horrible pattern to use - why split up the object initialization into two parts where one is obviously "The Wrong Think(tm)"?
Ideally, I'd like to see what is inside the super().tap { |o| block, because although this looks like bad practice, just maybe there is some interaction required before or after initialize is called.
Without context, it is possible that you are just looking at something that works but is not considered good practice in Ruby.
However, maybe the approach of separate self.new and initialize methods allows the framework designer to implement a subclass-able part of the framework and still ensure setup required for the framework is completed without slightly awkward documentation that requires a specific use of super(). It would be a slightly easier to document and cleaner-looking API if the end user gets functionality they expect with just the subclass class MyClass < FrameworkClass and without some additional note like:
When you implement the subclass initialize, remember to put super at the start, otherwise the magic won't work
. . . personally I'd find that design questionable, but I think there would at least be a clear motivation.
There might be deeper Ruby language reasons to have code run in a custom self.new block - for instance it may allow constructor to switch or alter the specific object (even returning an object of a different class) before returning it. However, I have very rarely seen such things done in practice, there is nearly always some other way of achieving the goals of such code without customising new.
Examples of custom/different Class.new methods raised in the comments:
Struct.new which can optionally take a class name and return objects of that dynamically created class.
In-table inheritance for ActiveRecord, which allows end user to load an object of unknown class from a table and receive the right object.
The latter one could possibly be avoided with a different ORM design for inheritance (although all such schemes have pros/cons).
The first one (Structs) is core to the language, so has to work like that now (although the designers could have chosen a different method name).
It's impossible to tell why that code is there without seeing the rest of the code.
However, there is something in your question I want to address:
As far as I understand, both self.new and initialize do the same thing - the latter one "during construction" and the former one "after construction"
They do not do the same thing.
Object construction in Ruby is performed in two steps: Class#allocate allocates a new empty object from the object space and sets its internal class pointer to self. Then, you initialize the empty object with some default values. Customarily, this initialization is performed by a method called initialize, but that is just a convention; the method can be called anything you like.
There is an additional helper method called Class#new which does nothing but perform the two steps in sequence, for the programmer's convenience:
class Class
def new(*args, &block)
obj = allocate
obj.send(:initialize, *args, &block)
obj
end
def allocate
obj = __MagicVM__.__allocate_an_empty_object_from_the_object_space__
obj.__set_internal_class_pointer__(self)
obj
end
end
class BasicObject
private def initialize(*) end
end
The constructor new has to be a class method since you start from where there is no instance; you can't be calling that method on a particular instance. On the other hand, an initialization routine initialize is better defined as an instance method because you want to do something specifically with a certain instance. Hence, Ruby is designed to internally call the instance method initialize on a new instance right after its creation by the class method new.
I'm having a hard time imagining a practical use for Procs and Lambdas in a web app. Does anyone have an example of a situation in your code where they come in handy?
Why in webapps in particular? Do you mean the Ruby on Rails framework, perhaps?
Procs and lambdas are useful when you want to store pieces of code anonymously. Procs and lambdas are very similar to methods, except that they don't have a name. A good example to illustrate this, in ActiveRecord/Rails:
// methods are named
validates_presence_of :foo, :if => :active?
// procs aren't
validates_presence_of :foo, :if => proc {|r| do_stuff }
I general, procs are used for callbacks and hooks, so that you don't have to write named methods and refer to them, putting the code in question directly in the option hashes and such.
You might find this article useful.
I use them on named scopes:
named_scope :last, lambda { |quantity| {:order => "created_at DESC", :limit=> quantity } }
To create an easy way to get the last NUMBER posts, comments, etc.
Now, I kinda cheated there, it's most of a framework thing than a "web app", but I can't think web app are that different from other desktop ones. Both Procs and Lambdas allows you to "save" code for later use, and can help to use behaviour, use more "domain oriented" methods and cleaning up some more "regular code"
Obviously, procs and lambdas are a necessary component of anything related to callbacks, but in most cases in ruby this can be accomplished with a block.
One place where procs or lambdas are useful that isn't related to callbacks is things like compiling a regular expression. Of course, regex are part of the language, so you don't need procs for this, but you may find yourself writing some other kind of procedure that has a one-time cost that can be reused, but isn't really worth creating a full blown class.
In my case, I had an object (publist) which contained a list of strings. In one area of the code, I needed to repeatedly check whether some other set had any members in that list. It would have been inconvenient and have poor performance to change the data type so that the object contained a set. So what I did was create a method that returned a matcher lambda that had a local set representation of this list.
I could have returned a set, but the business logic of whether an item matched logically belonged to the publist. I could in the future change this to support substrings or regular expressions and users of the matcher would still have the same api.
Using lambda or proc is a matter of programming style called functional programming. There are several interfaces in Rails where you might like to pass a block object(lambda or procc), just like validations:
class Person < ActiveRecord::Base
validates_acceptance_of :terms_of_service :if => Proc.new { |user| user.signup_step > 2 }
end
You can design some interfaces like that, where you can give the user the choice of either passing a method name(symbol) or a proc(or lambda) object to specify some logic.
Another place in Rails for example is where you can set layouts dynamically:
class WeblogController < ActionController::Base
layout proc{ |controller| current_user.logged_in? ? "writer_layout" : "reader_layout" }
end