I have a Ruby object #element that I used .inspect on. The result is below
#<Watir::Hidden:0x7b61410 located=false selector={:type=>"hidden", :tag_name=>"input", :id=>"foo"}>
How can I access "foo"
I've tried #element.id (which finds the ruby object id instead), #element[:id] and #element.selector[:id], #element['selector'][:id] etc.
Any help?
You can get attribute values using the attribute_value method:
#element.attribute_value("id")
Generally those are instance variables of an object. If they haven't exposed an attr_accessor, then you're touching private data, something that's generally frowned upon.
You can always get these if they are stored in an instance variable by using something like:
#element.instance_variable_get('#selector')[:id]
I wouldn't make use of this too extensively, it's a bad practice, but sometimes you have to do what you have to do.
In Ruby what is the difference between those two (in code):
Class.method
Class#method
It's a naming convention.
use pound #method for instance methods
use dot .method for class methods
See: How to name RSpec describe blocks for methods
The hash format (Class#method) is not valid ruby, but is used in documentation to describe an instance method.
Class methods are typically documented using a double-colon (Class::method).
You will see examples of both in the ruby docs (e.g. http://www.ruby-doc.org/core-1.9.3/String.html)
The dot format is used in code when actually calling a class method (Class.method), though I have seen some people (unfortunately) use it interchangeably with either the double-colon or hash in documentation.
Class#method is not valid code. It is only used in documentation. method should be an instance method.
Class.method or object.method is the actual method belonging to the object. Class is an object too. It is valid code.
In Ruby what is the difference between those two (in code):
Class.method
Class#method
It's a naming convention.
use pound #method for instance methods
use dot .method for class methods
See: How to name RSpec describe blocks for methods
The hash format (Class#method) is not valid ruby, but is used in documentation to describe an instance method.
Class methods are typically documented using a double-colon (Class::method).
You will see examples of both in the ruby docs (e.g. http://www.ruby-doc.org/core-1.9.3/String.html)
The dot format is used in code when actually calling a class method (Class.method), though I have seen some people (unfortunately) use it interchangeably with either the double-colon or hash in documentation.
Class#method is not valid code. It is only used in documentation. method should be an instance method.
Class.method or object.method is the actual method belonging to the object. Class is an object too. It is valid code.
I was working with Ruby and WIN32OLE (which is specifically, Excel).
I found all those enumerable objects, such as Range.Columns, are automatically enumerable in Ruby, and can be iterated using obj.each method.
I am wondering how it works? I understand that if you want to make something enumerable, you have to include "Enumerable". But apparently they cannot put that line in the OLE object. Is it just directly mapping obj.each method to for each loop?
There's an interesting set of posts here that might answer your question, specifically:
(...) each is called as
dynamically as any other OLE method; it's not determined before the
call whether or not the object actually implements IEnum.
and:
Enumerable#find method clashes the 'find' method of Excel Range
object. This is the (only) reason why WIN32OLE does not include
Enumerable.
WIN32OLE class has 'each' method (WIN32OLE#each is defined) (...)
Hope this helps!
method_missing
*obj.method_missing( symbol h , args i ) → other_obj
Invoked by Ruby when obj is sent a
message it cannot handle. symbol is
the symbol for the method called, and
args are any arguments that were
passed to it. The example below
creates a class Roman, which responds
to methods with names consisting of
roman numerals, returning the
corresponding integer values. A more
typical use of method_missing is to
implement proxies, delegators, and
forwarders.
class Roman
def roman_to_int(str)
# ...
end
def method_missing(method_id)
str = method_id.id2name
roman_to_int(str)
end
end
r = Roman.new
r.iv ! 4
r.xxiii ! 23
r.mm ! 2000
I just heard about method-missing and went to find out more in Programming Ruby but the above explanation quoted from the book is over my head. Does anyone have an easier explanation? More specifically, is method-missing only used by the interpreter or is there ever a need to call it directly in a program (assuming I'm just writing web apps, as opposed to writing code for NASA)?
It's probably best to not think of ruby as having methods. When you call a ruby "method" you are actually sending a message to that instance (or class) and if you have defined a handler for the message, it is used to process and return a value.
So method_missing is a special definition that gets called whenever ruby cannot find an apropriate handler. You could also think of it like a * method.
Ruby doesn't have any type enforcement, and likewise doesn't do any checking as to what methods an object has when the script is first parsed, because this can be dynamically changed as the application runs.
What method_missing does, is let you intercept and handle calls to methods that don't exist for a given object. This provides the under-the-hood power behind pretty much every DSL (domain-specific language) written in Ruby.
In the case of the example, every one of 'r.iv', 'r.mm', and so on is actually a method call to the Roman object. Of course, it doesn't have an 'iv' or an 'mm' method, so instead control is passed to method_missing, which gets the name of the method that was called, as well as whatever arguments were passed.
method_missing then converts the method name from a symbol to a string, and parses it as a Roman number, returning the output as an integer.
It's basically a catch-all for messages that don't match up to any methods. It's used extensively in active record for dynamic finders. It's what lets you write something like this:
SomeModel.find_by_name_and_number(a_name, a_number)
The Model doesn't contain code for that find_by, so method_missing is called which looks at is says - I recognize that format, and carries it out. If it doesn't, then you get a method not found error.
In the Roman example you provide it illustrates how you can extend the functionality of a class without explicitly defining methods.
r.iv is not a method so method_missing catches it and calls roman_to_int on the method id "iv"
It's also useful when you want to handle unrecognized methods elsewhere, like proxies, delegators, and forwarders, as the documentation states.
You do not call "method_missing" (the interpreter calls it). Rather, you define it (override it) for a class which you want to make to be more flexible. As mentioned in other comments, the interpreter will call your version of method_missing when the class (or instance) does not ("explicitly"?) define the requested method. This gives you a chance to make something up, based on the ersatz method/message name.
Have you ever done any "reflection" programming in Java? Using this method would be as if the class to be accessed via reflection could look at the string (excuse me, "symbol") of the method name if a no-such-method exception was thrown, and then make something up as that method's implementation on the fly.
Dynamic programming is kind of a "one-up" on reflection.
Since you mention web apps I'll guess that you are familiar with Ruby on Rails. A good example of how method_missing can be used is the different find_by_<whatever> methods that's available. None of those methods actually exist! They are synthesized during run time. All of this magic happens because of how ruby intercepts invocations of non-existing methods.
You can read more about that and other uses of method_missing here.
ActiveRecord uses method_missing to define find_by methods. But since, method_missing is basically a last resort method, this can be a serious performance bottleneck. What I discovered is that ActiveRecord does some further awesome metaprogramming by defining the new finder method as a class method !! Thus, any further calls to the same finder method would not hit the method_missing because it is now a class method. For details about the actual code snippet from base.rb, click here.