Similar to __callee__, is there something which returns the calling method? I realize there is the caller which I amble to strip the name of the caller method from but I am curious is there is a standard method for returning the name of the calling method without any other information along with it.
There is no such feature in MRI. But there are some alternatives.
In case you happen to use Rubinius, you can do this instead of parsing caller:
Rubinius::VM.backtrace(1, false).first.name
#=> :calling_method_name
You can also use a gem to parse the result of caller for you. It should work for any Ruby > 1.9.
The answer to this SO question describes how you can do some simple parsing yourself.
And finally, there appears to be work in progress on getting a feature like this into Ruby 2.0, although the relevant ticket has not been updated for a while.
Related
I've been re-learning Ruby lately, and this page says that usually a bang method is dangerous, but it doesn't say why. Why are bang methods dangerous?
There are two widespread meanings of "dangerous" in standard library and common gems:
Method mutates the receiver, as opposed to returning a copy of the receiver. Example: Array#map!
Method will raise an exception if its primary function can't be performed. Example: ActiveRecord::Base#save!, ActiveRecord::Base#create!. If, say, an object can't be saved (because it's not valid or whatever), save! will raise an error, while save will return false.
I usually add a third meaning to it in my code:
Method will immediately persist data in the database, instead of just changing some attributes and hoping that later someone will save the object. Example: hypothetical Article#approve!
The page you refer to includes this:
Normally for the built-in classes, dangerous usually (although not always) means this method, unlike its non-bang equivalent, permanently modifies its receiver.
The convention goes like this:
Firstly, you create a bang method only if you have a non-bang alternative with the same name.
Secondly - yes, it means that this version is "more dangerous". This is a very vague term as you said yourself.
In a lot of the standard library it will modify an object in place, instead of creating a new one. Sometimes it will return nil instead of the object if the call didn't require any modification.
In rails bang methods usually raise exceptions as opposed to returning nil.
Why are bang methods dangerous?
Because that's the naming convention: if there are two methods which do the same thing, then you name them both the same name but the more surprising or more dangerous one gets the bang.
For example, Process::exit and Process::exit! both exit the currently running Ruby process, but the bang version will skip running all exit handlers that may be installed, and so, for example, skip any cleanup that you might have scheduled for when your app exits.
No it is not dangerous. Bang methods simply means they are modifying the object itself and you should be careful.
I'm currently creating a my own plugin for Redmine. I found the following method in its core (not exact code, but the idea is preserved):
def method(foo, bar, array)
# Do some complex stuff with foo and bar
#array = array
#array.uniq!
#array = #array[0:3]
# Do some complex weird stuff with #array
end
I have to change this '3' to '6', because three elements in array is not enough for my plugin's purposes. I can change it manually and nothing crashes, but I don't want to patch Redmine's core. So, I'm writing a plugin which replaces this method with my own implementation, which does the same thing, but three is changed to six.
Here's the problem: if this file updates, outdated method will be used. Is there any way to check what's written inside method in runtime (for example, when server starts)?
By the way, is there any method to directly modify this constant without overriding the whole method?
If you are able to access the file, then you can use the pry gem to check the source code. Or without such gem, you can manually check the location of the method by doing puts method(:foo).source_location, and read that part.
The easiest for you to change the behaviour is to override the entire method.
No, there is no way to get a method's source code at runtime in Ruby. On some Ruby implementations there may be a way to get the source code which works some of the time, but that will be neither reliable nor portable. After all, there isn't even a guarantee that the source code will even be Ruby, since most implementations allow you to write methods in languages other than Ruby (e.g. C in YARV, Java in JRuby etc.)
Is there a way to find out more information of what a method does in irb.
Example would be in irb/pry I could do something like this:
strigy_object = "I am string"
Now if i type stringy_object. and press the tab key, all the possible methods that stringy_object responds to would be listed. Since I am relatively new to ruby and not really familiar with all the methods, I would love to possibly find more information about what the method does. In short, is there a 'man' command equivalent that could help me achieve that in irb/pry?
Use the show-doc command.
For some commands you'll need to gem install pry-doc (like for C commands).
Use stringy_object.methods. It will return with all the methods the object responds to.
If you want to trim down that list to only methods specific to that type of object, you can do stringy_object.methods - Object.methods.
I'm attempting to (for fun and profit) add the ability to inspect objects in ruby and discover their source code. Not the generated bytecode, and not some decompiled version of the internal representation, but the actual source that was parsed to create that object.
I was up quite late learning about Rubinius, and while I don't have my head around it yet fully, I think I've made some progress.
I'm having trouble figuring out how to do this, though. My first approach was to simply add another instance attribute to the AST structures (for, say, a ClosedScope object). Then, somehow pull that attribute out again when the bytecode is interpreted at runtime.
Does this seem like a sound approach?
As Mr Samuel says, you can just use pry and do show-source foo. But perhaps you'd like to know how it works under the hood.
Ruby provides two things that are useful: firstly you can get a list of all methods on an object. Just call foo.methods. Secondly it provides a file_name and line_number attribute for each method.
To find the entire source code for an object, we scan through all the methods and group them by where they are defined. We then scan up the file back until we see class or module or a few other ways rubyists use to define methods. We then scan forward in each file until we have identified the entire class/module definition.
As dgitized points out we often end up with multiple such definitions, if people have monkey patched core objects. By default pry only shows the module definition which contains most methods; but you can request the others with show-source -a.
Have you looked into Pry? It is a Ruby interpreter/debugger that claims to be able to do just what you've asked.
have you tried set_trace_func? It's not rubinius specific, but does what you ask and isn't based on pry or some other gem.
see http://www.ruby-doc.org/core-1.9.3/Kernel.html#method-i-set_trace_func
I have a series of Ruby methods andI would like to dump their return values out to a formatted report. However, I'd also like to annotate these results (i.e. with descriptions of what the value is), and I was wondering if I could use the existing comments on each method to do this annotating?
So I guess what I want to do is output the rdoc as normal but for each method actually run the method with an argument. The argument is the same for every single method, which simplifies it.
with 1.9 there is a Method#source_location that might be helpful for you (ripper might help,too).
Also note: http://github.com/rdp/arguments might be helpful