Clr Interop and private member variables


#1

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.


#2

Make it protected instead of private?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Orion E.
Sent: Monday, May 04, 2009 4:32 PM
To: removed_email_address@domain.invalid
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.


#3

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: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Orion E.
Sent: Monday, May 04, 2009 4:57 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Clr Interop and private member variables

It’s not my code :slight_smile:

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.
<removed_email_address@domain.invalidmailto:removed_email_address@domain.invalid> wrote:

Make it protected instead of private?


#4

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: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Curt
Hagenlocher
Sent: Monday, May 04, 2009 5:47 PM
To: removed_email_address@domain.invalid
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: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Orion E.
Sent: Monday, May 04, 2009 4:57 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Clr Interop and private member variables

It’s not my code :slight_smile:

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.
<removed_email_address@domain.invalidmailto:removed_email_address@domain.invalid> wrote:

Make it protected instead of private?


#5

It’s not my code :slight_smile:
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…