Private members should perhaps not be readable #16

d-led opened this Issue Jul 27, 2014 · 5 comments


None yet

2 participants

d-led commented Jul 27, 2014

As it seems, privates can be read from. The assertion fails:

lua.obj = new SomeObject();
string answer = lua("return")[0];
answer.Should().NotBe(new SomeObject().Name);


public class SomeObject
    string name = "SomeName";
    public string Name { get { return name; } }
nrother commented Jul 28, 2014

This issue is a bit complicated, but the main problem is not in DynamicLua but in NLua:
In this line of NLua BindingFlags.IgnoreCase it set. (According to the comment they had even BindingFlag.Private in there, but removed it). Since your private member is called name and your public property is called Name that one is found, since they search case-invariant.

So a simple workaround is to rename the property. Interestingly then your code returns name, instead of throwing an exception, which is a bit strange. (BTW: You don't need that [0], an DynamicArray containing exactly one element can be implicitly converting to it's containing value.)

Please note that the code throws the correct exception, when the access goes through DynamicLua, which is even a bit simpler that to return the value from Lua.

string answer =

So this basically a bad design decision in NLua... I'll close this issue as wont-fix, feel free to report it to NLua!

@nrother nrother closed this Jul 28, 2014
@nrother nrother added the wontfix label Jul 28, 2014
nrother commented Jul 28, 2014

I just reported this issue to NLua: NLua/NLua#98

d-led commented Jul 29, 2014


nrother commented Aug 23, 2014

They fixed it, so you could try using DynamicLua with a new version of the NLua.dll. Probably I will also push fixed version soon (or solve the dependency problem some other way, especially for Mono...)

d-led commented Aug 23, 2014


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment