Need explanation of some Ruby syntax - ruby

I am new to ruby on rails, could anybody explain what does the symbol ':' mean, what would be 'validates' and 'create_table'? So much confused...
class Post < ActiveRecord::Base
validates :name, :presence => true
validates :title, :presence => true, :length => {:minimum => 5}
end
class CreatePosts < ActiveRecord::Migration
def change
create_table :posts do |t|
t.string :name
t.string :title
t.text :content
t.timestamps
end
end
end

The colon character (:) is the beginning of a syntax literal for a Ruby "Symbol":
:abc.class # => Symbol
"abc".to_sym # => :abc
Symbols are like strings but they are "interned", meaning the Ruby interpreter only has a single copy of it in memory despite multiple possible references (whereas there can be many equivalent strings in memory at once).
The 'validates' token in your example above is a class method (of something in the class hierarchy of the "Post class") that is being called with a symbol argument (:name) and a hash argument with a single key/value pair of :presence => true.
The 'create_table' token is a method which is being called with a single argument (the symbol ":posts") and is given a block which takes a single argument "t" (do |t| ... end).

:foo is a symbol, i.e. a constant string that is guaranteed to be unique. They are often used in Ruby to reference fields or methods.
validates is used in ActiveRecord to set a constraint on field's values.
validates :name, :presence => true means that field name must be always set (not null, undefined or empty) for all instances of Post (and corresponding table in DB). validates :title, :presence => true, :length => {:minimum => 5} means that field title must be always set and its length must be greater than 5.

In Ruby, the : means that it is a Symbol. A Symbol is sort of like a lightweight string that's specifically used as an identifier. For example, in a hash, you use symbols as keys that point to their respective values.
my_hash = {:key_1 => "A", :key_2 => "B"}
In your examples above, you use symbols to specify the properties of your Post model and the columns of your posts table.
Here are a few links for further reading on Ruby symbols:
http://www.randomhacks.net/articles/2007/01/20/13-ways-of-looking-at-a-ruby-symbol
http://glu.ttono.us/articles/2005/08/19/understanding-ruby-symbols
http://www.ruby-doc.org/core/classes/Symbol.html
http://www.robertsosinski.com/2009/01/11/the-difference-between-ruby-symbols-and-strings/

:foo is a "symbol" which is essentially an immutable string. It's major advantage is the fact that it doesn't allocate a new object every time you use it. If you were to use the string "name" every time you needed to use it, you would be making a new String object every time. However, if you use :name instead, you are using the same Symbol object every time (same in terms of pointer equality and object identity).
validates and create_table are both methods. In ruby, a method doesn't need parenthesis when called, so validates :foo is the same as validates(:foo). The methods come via inheritance and module mixins. validates is a class method put onto ActiveRecord objects during the inheritance, and create_table is a instance method

Ruby Documentation and Ruby on Rails Documentation:
"what does the symbol : mean?" Class:Symbol
Symbol objects represent names and some strings inside the Ruby interpreter. They are generated using the :name and :"string" literals syntax, and by the various to_sym methods. The same Symbol object will be created for a given name or string for the duration of a program‘s execution, regardless of the context or meaning of that name. Thus if Fred is a constant in one context, a method in another, and a class in a third, the Symbol :Fred will be the same object in all three contexts.
"what would be validates?" ActiveModel::Validations::ClassMethods
This method is a shortcut to all default validators and any custom validator classes ending in ‘Validator’. Note that Rails default validators can be overridden inside specific classes by creating custom validator classes in their place such as PresenceValidator.
"what would be create_table?" ActiveRecord::ConnectionAdapters::SchemaStatements
Creates a new table
(The link shows examples, showing SQL statements generated by this method.)

#Grimm
As you should know, everything is object on RoR. There are cases where you need to differentiate String from others as the memory handling techniques of String are different from other data structures. Colon : is a form of consideration of such type. They're just symbols like the one that makes hash entry on the memory!
Get used to that, it'll be interesting!! :)

as everybody is saying, : is a start of a symbol. Symbol is simple a string or variable name for me. In your example, :name is a variable/symbol that reflect one of the field name in Post table. Rails automatically creates these symbols when you create a Model class.
In Ruby, you can call a method/function and specify their parameters with/without the brackets. So,
validates :name, :presence => true
can be written as
validates(:name, :presence => true)
So, you are actually passing the :name and the true as the parameters for validates method
hope this help you see clearer about the methods calling in Ruby.
Same as validates, create_table is also a method.

Apart from the symbols, the point to be noted here is that in Ruby, we dont have to implicitly give {} to specify that an argument is a hash if it is the last argument. I mean by calling
validates :name, :presence => true
you are calling
validates :name, {:presence => true}
or
validates(:name, {:presence => true})
then it becomes clear that you are calling a method validates with 2 arguments, a symbol and a hash. If we ignore the symbol and substitute strings in place, like this:
validates("name", {"presence" => true})
it is pretty much similar to a method call in any other language. So, watchout for this as it is used almost in every helper tags Rails use.
For the other methods also you can see this:
validates(:title, {:presence => true, :length => {:minimum => 5}})
In the case of create_table, it is a method call with 2 arguments, a symbol and a block.

Related

How to define method names and object references before actually having to use them (Ruby)

Say I am keeping track of email correspondances. An enquiry (from a customer) or a reply (from a supporter) is embedded in the order the two parties are corresponding about. They share the exact same logic when put into the database.
My problem is that even though I use the same logic, the object classes are different, the model fields I need to call are different, and the method names are different as well.
How do I put methods and objects references in before I actually have to use them? Does a "string_to_method" method exists or something like that?
Sample code with commentaries:
class Email
include Mongoid::Document
field :from, type: String
field :to, type: String
field :subject, type: String
belongs_to :order, :inverse_of => :emails
def start
email = Email.create!(:from => "sender#example.com", :to => "recipient#example.com", :subject => "Hello")
from_or_to = from # This represents the database field from where I later on will fetch the customers email address. It is either from or to.
enquiries_or_replies = enquiries # This represents a method that should later be called. It is either enquiries or replies.
self.test_if_enquiry_or_reply(from_or_to, enquiries_or_replies)
end
def test_if_enquiry_or_reply(from_or_to, enquiries_or_replies)
order = Order.add_enquiry_or_reply(self, from_or_to, enquiries_or_replies)
self.order = order
self.save
end
end
class Order
include Mongoid::Document
field :email_address, type: String
has_many :emails, :inverse_of => :order
embeds_many :enquiries, :inverse_of => :order
embeds_many :replies, :inverse_of => :order
def self.add_enquiry_or_reply(email, from_or_to, enquiries_or_replies)
order = Order.where(:email_address => email.from_or_to).first # from_or_to could either be from or to.
order.enquiries_or_replies.create!(subject: email.subject) # enquiries_or_replies could either be enquiries or replies.
order
end
end
Judging by the question and the code sample, it sounds like you are mixing concerns too much. My first suggestion would be to re-evaluate your method names and object structure. Ambiguous names like test_if_thing1_or_thing2 and from_or_to (it should just be one thing) will make it very hard for others, and your future self, to understand the code laster.
However, without diverging into a debate on separation of concerns, you can change the methods you call by using public_send (or the private aware send). So you can do
order.public_send(:replies).create!
order.public_send(:enquiries).create!
string to method does exist, it's called eval
so, you could do
method_name = "name"
eval(method_name) #calls the name method

field vs method ruby on rails

I have this class:
class User
include Mongoid::Document
field :revenues, :type => Integer, :default => nil
attr_accessible :revenues
#now method
def revenues
return 1
end
end
Why in console I get 1 instead nil?
1.9.3-p125 :002 > u.revenues
=> 1
Which has priority, the method or the field? How can I created a method with the same features that a field?
The field macro is defined in Mongoid::Document. It is neither a syntatic feature from Ruby nor from Rails.
What's happening with your code is the following:
The field function creates for you some methods, one of them is called revenues.
When you create another method called revenues, you are in effect overwriting the previously defined method, therefore making it useless.
Short answer: I don't understand a zip about Mongoid, but chances are that your field still exists even after you defined oce again a method named revenues. The only drawback is that you cannot access it by calling myUser.revenues anymore.
Try to make a test: access your field with the notation some_user[:revenues] and see what happen :)
Best regards

Rails -- self vs. #

I am following Michael Hartl's RoR tutorial, and it is covering the basics of password encryption. This is the User model as it currently stands:
class User < ActiveRecord::Base
attr_accessor :password
attr_accessible :name, :email,: password, :password_confirmation
email_regex = /^[A-Za-z0-9._+-]+#[A-Za-z0-9._-]+\.[A-Za-z0-9._-]+[A-Za-z]$/
#tests for valid email addresses.
validates :name, :presence => true,
:length => {:maximum => 50}
validates :email, :presence => true,
:format => {:with => email_regex},
:uniqueness => {:case_sensitive => false}
validates :password, :presence => true,
:length => {:maximum => 20, :minimum => 6},
:confirmation => true
before_save :encrypt_password
private
def encrypt_password
self.encrypted_password = encrypt(password)
end
def encrypt(string)
string
end
end
I posted a previous question about before_save not working, and it turns out that what I had accidentally done is written my encrypt_password as:
def encrypt_password
#encrypted_password = encrypt(password)
end
I understand that if self.encrypted_password sets the encrypted_password attribute, but why does #encrypted_password not do that as well? In the response to the previous post about before_save not working someone said that the instance variable was "forgotten" after the method ended with the way I had originally coded it -- why was this the case? Can someone please explain how self and # work differently in the context of the code above?
NOTE: I already took a look at the posts here and here, but they both say that "self" is calling the attribute = method, and I don't even understand how that method could exist here since I never created it or declared the encrypted_password w/ attr_accessor. So I am still confused, and this is not a re-posting of those questions.
The accessors for encrypted_password have been automatically added by Rails for you because a field by that name exists in the users table.
Any field you add to a table will be automatically made available via self.field_name.
Here is where Michael Hartl's tutorial creates the encrypted_password field in the users table.
Also look at the user_spec.rb (Listing 7.3) in the linked page, where the author is testing for the presence of the encrypted_password field.
UPDATED:
As #mu points out, the # is used for Ruby instance variables (aka "iv"). But encrypted_password is an "attribute" defined by Rails, and is not an instance variable.
If you run User.find(1).instance_variables, you will see that there is an iv called #attributes, which is of type Hash.
Inside that iv is where the encrypted_password is stored. Rails has defined accessor methods for encrypted_password, which gets/sets the data for that
attribute in the #attributes Hash.
Note that you could also get/set the data via #attributes["encrypted_password"] called from within the User class (but the accessor methods are convenient way to do just that).
If you let me, I'd like to rephrase the answer.
I explained in this post, that as soon as you create a (rails-) Model with the same (singular) name as one of the (plural) tablenames of your database, the "magic" of rails will create setters and getters in order to modify your table's records.
This is because your model inherits all methods from the ActiveRecord::Base Class, which defines basic CRUD accessors (Create, Read, Update, Delete).
The key point related to your question, is that you don't know how rails implements the instance variable related to your database table column, And you shouldn't. :) All you have to know is that at that point, you have setters and getters available to CRUD (create, read, update, delete) your database column "encrypted_password".
In your example, maybe rails uses an instance variable called #encrypted_password, maybe rails uses an hash-instance-variable called #attributes["encrypted_password"], or maybe rails uses an instance variable called #you_will_never_guess_encrypted_password.
-
And that's a good point you don't know about the internal rails behavior with instance variables. In 2019 Rails further development may lead the framework to use #complicated-hash-instance-variable to store the encrypted_password value.
In fact the best approach is to let rails manage its "private" "affair" ;) with instance variables, and just use the getter and setter methods it provides to you.
So your application will still work with encrypted_password in the next century (I hope so ^^).
So if you use #encrypted_password it may work with some "imaginary" version of rails and it won't work anymore with other rails versions. Actually with a current version of rails it doesn't work.
-
The second key point is that when you want to use the getter "encrypted_password" Rails created for your encrypted_password database table column, you prefix it with "self" in order to tells Ruby : "ok I want to use the encrypted_password method of my User instance variable."
In Ruby, a method is called by passing its name to a receiver.
You write it like this :
my_receiver.my_method
In your case we pass the method encrypted_password to the User instance variable. But we don't know how this instance variable will be named, so we use the word self to tell Ruby : "I'm talking about any instance variable of the User class that calls the encrypted_password method".
For instance we could have named our instance variable "toto" :
toto = User.new
so toto.encrypted_password would display the encrypted password, and self in this very case in our code would reference toto.
However, thanks to Ruby, if you don't give any receiver when calling a method, Ruby will assume you pass it to self.
Reference : Pragmatic Programmer's guide
So in your example, you even don't need to put "self." as prefix.
You could have it written like this :
class User < ActiveRecord::Base
def encrypt_password
encrypted_password = encrypt(password)
end
end
I hope this helps to clarify this interesting subject.
TL;DR -
Always write self.widget_count = 123 if you intend to save widget_count back to the database.
(But please do read the long answers, as the reason why is valuable to know.)

Is 'valid' a reserved name in DataMapper?

I have the following model in datamapper:
class Student
include DataMapper::Resource
property :id, Serial
# <snip>
property :permissions, String, :accessor => :protected, :required => true, :default => 'standard'
property :valid, Boolean, :default => false, :required => true
# <snip>
end
After requiring 'dm-validations' (version 1.1.0), and starting my Sinatra app, I recieve the following message:
/Library/Ruby/Gems/1.8/gems/dm-validations-1.1.0/lib/dm-validations.rb:81:in `valid?': wrong number of arguments (1 for 0) (ArgumentError)
from /Library/Ruby/Gems/1.8/gems/dm-validations-1.1.0/lib/dm-validations.rb:81:in `save_self'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource.rb:1007:in `_save'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource.rb:1223:in `run_once'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource.rb:1006:in `_save'
from /Library/Ruby/Gems/1.8/gems/dm-core-1.1.0/lib/dm-core/resource.rb:406:in `save'
from /Library/Ruby/Gems/1.8/gems/dm-validations-1.1.0/lib/dm-validations.rb:69:in `save'
from /Library/Ruby/Gems/1.8/gems/dm-validations-1.1.0/lib/dm-validations/support/context.rb:30:in `validation_context'
from /Library/Ruby/Gems/1.8/gems/dm-validations-1.1.0/lib/dm-validations.rb:69:in `save'
<snip>
Is the 'valid' name I'm using for my model a reserved word? If it is, where can I find these words. I'm to the point of going on to trying to name it something like: 'student_valid' but now i'm just really curious about this.
Thanks
#valid? is a method that dm-validations adds. You cannot use "valid" as a property name because it automatically defines "valid?" method for a boolean property type which overrides dm-validations' valid?. Hence the error.
That's a tricky situation, I guess we need to improve the way we validate property names. Thanks for reporting this.
Well the way datamapper works, is that it uses method_missing at the end of the method call chain and finds your property. If there is a method with this same name then that is called rather than your property. Datamapper mixes in Validatable which has the method valid? Most of the time you learn what is reserved (Like all Object methods etc.) But if you want a full list you can do:
`myinstance.methods`
Anything that appears there will get called first.

DataMapper has n with conditions

By any chance is it possible to create a conditional association with DataMapper?
For example:
I want the User have n Apps just if that user have the attribute :developer => true
something like this:
class User
include DataMapper::Resource
property :id, Serial
property :name, String, :nullable => false
property :screen_name, String, :nullable => false, :unique => true
property :email, String, :nullable => false, :unique => true, :format => :email_address
property :password, BCryptHash, :nullable => false
property :developer, Boolean, :default => false
#The user just gets apps if developer
has n :apps #,:conditions => "developer = 't'"
end
class App
include DataMapper::Resource
property :id, Serial
property :name, String, :nullable => false
belongs_to :user
end
I know that this would be possible by creating a subclass from User as a Developer::User and in that class, use the has n, but I really would like to know if its possible to make it directly on the association declaration.
Another way I also managed to do when using ARn was to extend the association and rewriting the methods for each action.
So on the extension module I could have something like this:
module PreventDeveloperActions
def new
if proxy_owner.developer?
super
else
raise NoMethodError, "Only Developers can create new applications"
end
end
# and so on for all the actions ...
end
But again, I really would like to avoid the use of this solutions if possible, but just if it's possible to perform a quick and direct method easily with DataMapper :)
Thanks in advance
At the moment, conditions that you include in the relationship declaration only apply to the target. So if the target model has an :active property, you can say things like has n, :apps, :active => true. Unfortunately you can't define relationships that are only active given the current state of the source (yet).
There are some proposals I'm considering to expand the Query logic in DM, but I'm unsure what the impact will be to the code, and what extra capabilities it will provide aside from this. It may be something we tackle after DM 1.0, since it also affects 50+ adapters and plugins.
STI is normally what I'd recommend for something like this, since it will allow you to define relationships that only exist for that type of object. Another approach would be to define the relationships as normal, mark the accessor/mutator methods as private, and then add a proxy method that does the equivalent of return apps if developer?.

Resources