Hello,

So I've been successfully using AngelScript in my personal project, but I ran into an issue which was unexpected. I have the following setup:

[module A]

shared interface IInterface
{
}

shared class SBaseClass
{
}

[module B]

shared class SClass : SBaseClass
{
    IInterface@ Prop
    {
        set
        {
            ...
        }
    }
}

[module C]

shared class SomeClass : IInterface
{
}

Now in my code I have a handle to an object of type SClass and I request the function ID of the Prop setter like this:

const auto pType = hObject->GetObjectType();
if (pType)
{
    const auto pFunc = pType->GetMethodByDecl("void set_Prop(SomeClass@)");
}

Now this fails to find the method declaration, because it can't find the SomeClass type. That's because the script engine takes the module of the first method to start looking for the type (module A in this case) and it seems the modules only look in types directly registered with the engine or that were parsed inside the module itself. I would've expected shared types to be checked here too.

I can work around this, but was wondering if this was intended behaviour, an oversight or if I'm simply missing something. Thanks for any and all help!

Is using

pType->GetMethodByDecl("void set_Prop(SomeClass@)");

not a mistake? Based on the actual interface one would expect to see

pType->GetMethodByDecl("void set_Prop(IInterface@)");

It sounds like you might not be using shared classes correctly, you can read more about them here:
https://www.angelcode.com/angelscript/sdk/docs/manual/doc_script_shared.html

It's mentioned that "in order to work the scripts in all modules that share the entity must implement the entity the same way", so all modules are expected to contain the shared classes. The thing to be carefull here is that I think when I tested the shared classes were "owned" by the first module that was loaded with them and if that module gets disposed, the shared classes it owned get destroyed even if other modules were using them (not sure if it's a bug or intended).
That page also gives the alternative to having duplicate class definitions in a form of "external" keyword.

I know it's not the exact type, but since these are properties I'm loading from a data file I was hoping I didn't need to use the exact type. IE AngelScript would be smart enough to downcast or get the implemented interfaces to match the function signatures. Looking deeper at the source this doesn't look like it'd be the case unfortunately.

But aside from that looking at that comment, I think you're right and what I'm seeing is intended behaviour: All modules need to contain the types. I assumed these types would be shared across modules by default, but no such luck

GetMethodByDecl requires the exact type when doing the lookup to find a specific method. However, since you have a shared interface it shouldn't be hard for you to figure out which type it should be, since all will be the same, right?

If on the other hand you want to be able to match different methods based on the type, then you'll need to do a bit more work to first enumerate all methods of the same name and then check the arguments for matching type. The API has everything you need to be able to do that if you really need it.

A module only 'sees' types that have been registered by the application, or declared within the module. If the type is declared as 'shared' then the type will be shared with other modules that declare the same type, which allow you to pass an instance of the type between one module to another. Note, a non-shared script class can implement a shared interface and still be shared with other modules, as long as the modules only interact with the class through the shared interface.