internal interface IConstructor

[viceice]

Was this intentional to no longer make that interface public? I use that for a custom type, which implements this interface.

jint/Jint/Native/IConstructor.cs

Line 5 in fe4ee89

internal interface IConstructor

I'm basicall doing something like this:

jint/Jint.Tests/Runtime/Domain/UuidConstructor.cs

Line 11 in fe4ee89

internal sealed class UuidConstructor : FunctionInstance, IConstructor

changed in v3.0.0-beta-2038 via

• Add Engine.Construct method #1047

[viceice]

I also see PR

• Hide Call method from public API #1062

So what's the new way to vreate custom types like the Uuid? I really need that that's why i send the initial test.

[lahma]

Well the idea is to hide as much as possible during while still in beta phase. Not just to irritate people, trying to find how much can be hidden and allow some wiggle room for change. Ideally all test cases should cover public API needs, can you create a PR to show what is needed?

IConstructor would ideally be internal, but maybe we could understand better with an example of usage. Is it basically adding new JS objects that need to be available?

[viceice]

maybe there is now a better way to handle / implement such a type?

[lahma]

OK I see your point, some things are visible via the InternalsVisibleTo, it definitely not the intention to make such extension points hard.

[viceice]

So how to go forward?

[viceice]

Should we make the test classes public, so it will force the interfaces to be public too?

[lahma]

I've created #1144 to track this. Maybe needs a little thought how to make it work. Custom JS object constructors are not a common thing (I guess?), maybe registration via options would work here.