I have the following C# class
namespace MyNamespace
{
public class MyObject
{
private string m_Name;
}
}
and I’m extending it from IronRuby
class MyNameSpace::MyObject
def printme
puts m_Name
end
end
When I try to run this, I get undefined method `m_Name’ for
MyNameSpace::MyObject (NoMethodError)
Other normal method/property calls work fine.
Likewise if I do MyObject.new.instance_eval{ m_Name } the same error
occurs.
Is this because IronRuby is trying to call a method instead of read a
member
variable, or is it because the variable is private?
Either way, is there a way I can fix this? (short of falling back
to InvokeMember…)
Thanks, Orion.
Make it protected instead of private?
From: [email protected]
[mailto:[email protected]] On Behalf Of Orion E.
Sent: Monday, May 04, 2009 4:32 PM
To: [email protected]
Subject: [Ironruby-core] Clr Interop and private member variables
I have the following C# class
namespace MyNamespace
{
public class MyObject
{
private string m_Name;
}
}
and I’m extending it from IronRuby
class MyNameSpace::MyObject
def printme
puts m_Name
end
end
When I try to run this, I get undefined method `m_Name’ for
MyNameSpace::MyObject (NoMethodError)
Other normal method/property calls work fine.
Likewise if I do MyObject.new.instance_eval{ m_Name } the same error
occurs.
Is this because IronRuby is trying to call a method instead of read a
member variable, or is it because the variable is private?
Either way, is there a way I can fix this? (short of falling back to
InvokeMember…)
Thanks, Orion.
Yes, that’s right. As Jim said, you can use -X:PrivateBinding to work
around this, but I don’t remember if this has any other consequences.
From: [email protected]
[mailto:[email protected]] On Behalf Of Orion E.
Sent: Monday, May 04, 2009 4:57 PM
To: [email protected]
Subject: Re: [Ironruby-core] Clr Interop and private member variables
It’s not my code 
It appears as though “extending” a class in ruby is more or less the
same as creating a derived class… is this right?
Might have to convince the other guy that “restricted by default” is not
the best philosophy…
On Tue, May 5, 2009 at 11:34 AM, Curt H.
<[email protected]mailto:[email protected]> wrote:
Make it protected instead of private?
PrivateBinding doesn’t mostly work in IronRuby yet (we will fix that).
Note that the call to a private method/reading a private field will be
much slower than if it was public. Also, it won’t work in partial trust
(anywhere where your app is not granted full access to all .NET
features, like in Silverlight, ASP.NET, etc.). I strongly suggest not to
access private members unless you are writing unit tests for C# code.
Tomas
From: [email protected]
[mailto:[email protected]] On Behalf Of Curt
Hagenlocher
Sent: Monday, May 04, 2009 5:47 PM
To: [email protected]
Subject: Re: [Ironruby-core] Clr Interop and private member variables
Yes, that’s right. As Jim said, you can use -X:PrivateBinding to work
around this, but I don’t remember if this has any other consequences.
From: [email protected]
[mailto:[email protected]] On Behalf Of Orion E.
Sent: Monday, May 04, 2009 4:57 PM
To: [email protected]
Subject: Re: [Ironruby-core] Clr Interop and private member variables
It’s not my code
It appears as though “extending” a class in ruby is more or less the
same as creating a derived class… is this right?
Might have to convince the other guy that “restricted by default” is not
the best philosophy…
On Tue, May 5, 2009 at 11:34 AM, Curt H.
<[email protected]mailto:[email protected]> wrote:
Make it protected instead of private?
It’s not my code 
It appears as though “extending” a class in ruby is more or less the
same as
creating a derived class… is this right?
Might have to convince the other guy that “restricted by default” is not
the
best philosophy…