moonsharp icon indicating copy to clipboard operation
moonsharp copied to clipboard

Inheritance for static objects

Open devedse opened this issue 8 years ago • 2 comments

Hi all,

I was playing around with instantiating some GameObjects from LUA but ran into the problem that the GameObject.Instantiate() method doesn't seem to be available if I just use the following code:

var interpreter = new Script();
UserData.RegisterType<GameObject>(); 
UserData.RegisterType<UnityEngine.Object>(); 

interpreter.Globals["GameObject"] = UserData.CreateStatic<GameObject>();

It keeps complaining that the Instantiate field cannot be found.

However when I change the last line to this:

interpreter.Globals["GameObject"] = UserData.CreateStatic<UnityEngine.Object>();

Then it does work.

It seems that inheritance is not working in my case for static objects. Is this desired functionality or might this be a missing feature?

(Also, is there a better way to work around this?)

devedse avatar Jan 16 '17 12:01 devedse

Mmmmh... missing feature I guess - I'll try, sorry!

[btw, for a few weeks/months support will be reduced as I'm changing job twice this year :( sorry in advance if this will take time]

xanathar avatar Jan 23 '17 15:01 xanathar

It seems like the BindingFlags.FlattenHierarchy item was made specifically for this purpse.

Doc: https://msdn.microsoft.com/en-us/library/cexkb29a(v=vs.110).aspx

Specifies that public and protected static members up the hierarchy should be returned. Private static members in inherited classes are not returned. Static members include fields, methods, events, and properties. Nested types are not returned.

I've tested it with the Windows 10 CLR framework and it worked without breaking anything else.

The RuntimeReflectionExtensions.GetRuntimeMethods method that is used in FrameworkWin8 does not use BindingFlags.FlattenHierarchy.

@xanathar Type.GetMethods exists in .net core (via TypeExtensions) and works as expected. Why was GetRuntimeMethods chosen instead? Also, FrameworkWin8 seems to exist only for the .net core build, however I have trouble understanding all the implications, but it seems like those Compatibility classes have existed for a long time and may be a bit out of touch, particularly the #if !NETFX_CORE || DOTNET_CORE seems wrong to me. Is there some overview anywhere how all this platform stuff came to be?

bplu4t2f avatar Jan 29 '17 19:01 bplu4t2f