I have problem how to know which function is used, cause here is multiple implementation. How rails know which function is correct. How you solve this problem in Ruby, is there way to tell IDE which function will be used
You can use Ruby's Method#source_location
http://ruby-doc.org/core-2.5.1/Method.html#method-i-source_location
You can use it with binding.pry as Stefan suggested or just print the result of #source_location before actually calling specific method (so you can be sure that the scope is the same).
Related
Recently I came across a method, which looks like: add(1).(2).
It was on Code Wars. I just should take this 2 argumenst and make them equated 3. It's easy part, I think, but I have never seen any arguments like this(I am newbie).
Do you have a source where I could read about it? Or could you explain it?
If you need more information, I take this example from here: https://www.codewars.com/kata/539a0e4d85e3425cb0000a88/train/ruby
This is a shorthand notation to call a proc or lambda expression
proc.call(arg)
proc[arg]
proc.(arg)
proc::(arg)
Are all equivalent.
Actually this works with any object that responds to call since Ruby is duck-typed like that.
I am submitting solutions to Ruby puzzles on codewars.com and experimenting with how locked into the testing enviroment I am for one of the challenges.
I can redefine the classes used to test my solution but they are defined by the system after I submit my code. If I freeze these objects, the system cannot write over them but a RunTime error is raised when it tries to.
I'm fairly new to Ruby, so I'm not sure which parts (other than falsiness and truthiness) are impossible to override. Can I use Ruby code to force modification of frozen objects to silently fail instead of terminate the program or is that bound up in untouchable things like the assignment operator or similar?
The real answer here is that if you might want to modify an object later, you shouldn't freeze it. That's inherent in the whole concept of "freezing" an object. But since you asked, note that you can test whether an object is frozen with:
obj.frozen?
So if those pesky RuntimeErrors are getting you down, one solution is to use a guard clause like:
obj.do_something! if !obj.frozen?
If you want to make the guard clauses implicit, you can redefine the "problem" methods using a monkey patch:
class Array
# there are a couple other ways to do this
# read up on Ruby metaprogramming if you want to know
alias :__pop__ :pop
def pop
frozen? ? nil : __pop__
end
end
If you want your code to work seamlessly with any and all Ruby libraries/gems, adding behavior to built-in methods like this is probably a bad idea. In this case, I doubt it will cause any problems, but whenever you choose to start hacking on Ruby's core classes, you have to be ready for the possible consequences.
I require different behavior from ActiveRecord::AttributeAssignment.assign_attributes(new_attributes, options).
For my entire web application, I want to evaluate [and frequently overwrite] new_attributes. (I want to do this to support third party UI widgets which do not follow rails form naming conventions). Although this might be a bit stinky, I can write the patch to only activate if the call did come from the third party form.
I have written a patch and can override the normal behavior; however, I'm wondering if it is possible to call the original method from within my patch?
Of course I can just cut and paste the original assign_attributes into my patch. Is there a better way?
alias_method_chain exists for this exact situation.
It's not always the right choice, but works well when you have a fitting use case, which this one looks to be.
alias or alias_method should do the trick, see
Ruby at about.com: aliasing
Is there any possibility to establish in method_missing declaration in Ruby whether a given missing_method was called (without any arguments) using parentheses notation, ie:
foo.non_existing_method()
or using parentheses-less notation:
foo.non_existing_method
?
I need this to solve my very specific testing problem.
No.
Since both are exactly the same, there cannot possibly be a way to detect the difference.
It doesn't make sense anyway, since both are exactly the same, so there cannot possibly any behavorial difference, either.
If you could detect the difference, then you could also have your method behave differently, which would be extremely surprising to any user of that method.
I'm new to Ruby so forgive me if this is something obvious..
I've made a class like so
class Element
attr_accessor :type
:type_integer
:type_string
end
(this is really just an example, not actual code)
Well, I've read Enums in Ruby and I'd prefer to go the Symbols route of having something like enumerations in other languages. I have a problem though, how can I keep my global scope clear while implementing this. What I'm wanting to be able to do is something like
e=Element.new
e.type=Element.type_integer
or something pretty simple and straight forward like that.
Symbols don't do anything to the global (or any other) scope (i.e. no variables or constants or anything else gets defined when you use symbols), so I guess the answer is: just use symbols and the global scope will be kept clear.
If you want to use e.type=Element.type_integer, while still using symbols, you could do:
class Element
def self.type_integer
:type_integer
end
end
Although I fail to see the upside vs. just using e.type = :type_integer directly.