Not docs yet, but they are coming. They are all for better .NET
integration. Let me give you a little bit of the docs I’m working on:
to_clr_type is to get the actual CLR Type object from a constant, if
that constant represents a CLR Type. For example:
System::String.class
=> Class
In .NET, String is of type System.RuntimeType, but Ruby says it’s a
Class, because it is mapped to a Ruby class. To get the actual CLR type,
you use to_clr_type:
System::String.to_clr_type.class
=> System::RuntimeType
clr_member is the get the actual member (property, field, method, etc)
from a .NET type. When you do System::String.method(:Replace), you’ll
get a method object pointing to the “Replace” method on Ruby’s String
class. However, you can’t be sure it’s the method from System::String
since “Replace” could have been monkey-patched on Ruby’s String.
clr_member will ensure you get the method object from the CLR Type.
class System::String
… def Replace(a, b)
… raise “BOOM”
… end
… end
=> nilSystem::String.new(“a”).method(:Replace).call(“a”, “b”)
:2:in `Replace’: BOOM (RuntimeError)
from :0
System::String.new(“a”).clr_member(:Replace).call(“a”, “b”)
=> ‘b’
clr_ctor lets you explicitly call a CLR types constructor. There are
some CLR types which map directly to Ruby types (for example:
System.Threading.Thread -> Thread … call “Thread.to_clr_type”). So:
System::Threading::Thread.new
:0:in `start’: must be called with a block (ThreadError)
from :0
Eek! What happened? Because the classes are mapped, this actually calls
Ruby’s Thread constructor. Doing System::Threading::Thread.clr_ctor will
give you the method object for the actual CLR constructor, allowing you
to call it directly.
to_clr_string is a convenience method on String which is basically this:
class String
def to_clr_string
System::String.new(self)
end
end
This is needed since a Ruby string is mutable, and a CLR string is
immutable, so they don’t map on to each other. You can still call any
immutable Ruby methods on a CLR string, but they are different types. So
for interop with CLR code which expects a CLR string, it’s useful to do
“foo”.to_clr_string. However, I think we do conversions between these
today, it’s not necessary, but still good to have.
Hope that helps. Let me know if you need any further clarification.
Also, if anyone sees anything incorrect, please let me know, as I just
wrote it =)
~js
