-
-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support explicit interface and hidden member of super class #1613
Conversation
…of super class Add field `_clrType` to `ObjectWrapper` Add `unwrapClr` helper method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work and kudos for the great test coverage!
I think this PR is making all Edit: I'll try to make a minimal test case in a few ( |
The following Assertion will fail for this PR. public class Container
{
public Child Child => _child;
Child _child = new Child();
public BaseClass Get()
{
return _child;
}
}
public class BaseClass
{
public int index = 123;
}
public class Child : BaseClass { }
[Fact]
public void CustomTest()
{
var engine = new Engine().SetValue("container", new Container());
var res = engine.Evaluate(@"container.Child === container.Get()"); // These two should be the same object. But this PR makes `container.Get()` return a different object
Assert.True(res.AsBoolean());
} Also in the context of Unity, if Child and BaseClass contain |
@CreepGin , I think this behavior is as design. Assert.False(engine.Evaluate(@"container.Child === container.Get()").AsBoolean()); // as design
Assert.True(engine.Evaluate(@"container.Child == container.Get()").AsBoolean()); // TODO BTW, it provides Assert.True(engine.Evaluate(@"container.Child === clrHelper.unwrap(container.Get())").AsBoolean()); |
So this is quite a big breaking change, at least for me. Now the "wrapped" version of the object is making all the I just tried |
public interface I1
{
string MethodFromInterface();
}
public class C1 : I1
{
public extern string MethodFromInterface();
public extern string MethodInClass();
public static I1 InterfaceInstance => new C1();
} Prepare js tests: var i1 = C1.InterfaceInstance; // typed ObjectWrapper with type I1
i1.MethodFromInterface(); // should success, if you cannot call it, fire an issue
i1.MethodInClass(); // failed as design, you wanna this works?
clrHelper.unwrap(i1).MethodInClass(); // should success, if you cannot call it, fire an issue
clrHelper.wrap(i1, C1).MethodInClass(); // it's better than just unwrap, like explicit conversion in C# ((C1)i1).MethodInClass(); |
i1.MethodInClass(); // failed as design, you wanna this works? Yes. But maybe make explicit interface optional (via Jint.Options)? Or provide a way to disable it? (If this is already the case, please let me know; I must've missed it) I do think the old behaviour should also be useful for a dynamic language like JS. (A good chunk of my codebase depends on it too) |
Close #1611 Support explicit interface and hidden member of super class
Add field
_clrType
toObjectWrapper
Add
unwrapClr
helper method