Page MenuHomePhabricator

mono: introduce friend assembly
ClosedPublic

Authored by YOhoho on Oct 10 2019, 4:03 AM.

Details

Summary

Friend assemblies can access efl_mono assembly's internal types and members.
If build-tests option is true, efl-mono-suite.exe and efl_mono_test.dll
will become friend assemblies.

Test Plan

meson setup -Dbindings=mono,cxx -Dmono-beta=true

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
YOhoho created this revision.Oct 10 2019, 4:03 AM
YOhoho requested review of this revision.Oct 10 2019, 4:03 AM

The idea is to make those should be public because third parties libraries' generated code may use it but should be hidden from the C# dev API elements actually internal, right?

The cost would be that any external library that would try to generate C# code from eo files will have to have a custom-built EFL# in order to add itself to the list of friends, no?

Right now we have only Tizen but this could make it harder to further expand EFL# for other libraries, like E (when it makes the switch).

Sorry, I do not understand why would another assembly want to access EFL's internal types.
@YOhoho Can you give an usage example?

Sorry, I do not understand why would another assembly want to access EFL's internal types.
@YOhoho Can you give an usage example?

When third parties libraries want to use generated classes from eolian_mono(from .eo files), they need to access EFL#'s internal types. for example, you can produce compiler error with D10339.

FAILED: src/tests/efl_mono/efl_mono_test.dll
mcs -d:EFL_BETA -target:library -out:src/tests/efl_mono/efl_mono_test.dll -r:src/bindings/mono/efl_mono.dll src/tests/efl_mono/dummy_child.eo.cs src/tests/efl_mono/dummy_numberwrapper.eo.cs src/tests/efl_mono/dummy_test_object.eo.cs src/tests/efl_mono/dummy_test_iface.eo.cs src/tests/efl_mono/dummy_inherit_helper.eo.cs src/tests/efl_mono/dummy_inherit_iface.eo.cs src/tests/efl_mono/dummy_part_holder.eo.cs src/tests/efl_mono/dummy_event_manager.eo.cs src/tests/efl_mono/dummy_constructible_object.eo.cs
src/tests/efl_mono/dummy_part_holder.eo.cs(84,55): error CS0122: `Efl.PartConcrete.NativeMethods.efl_part_get_ptr' is inaccessible due to its protection level

Hmmm... so your use case is a company wanting to extend EFL by creating a library which can be accessed BOTH from C and C#, right? Is that why you need to use EO files?

yes, exactly.
Mono test case cover that use cases.

OK, I agree we need to cover that case. I'll let @lauromoura judge if this is the best solution.
I am no expert in C#, but I think this should be achievable by third-party companies without having to recompile EFL#.

Currently the use case for the test library - besides testing EFL# itself - is creating a new library with new eolian-based types (.eo files). To mimic what one could do with Tizen's (today), Enlightenment's (in the future), or any other .eo based lib.

And you can do this, today, without the friendly info, right? Or is there a Tizen ELF# use case where the devs are accessing members that are currently internals?

But the cost of our current (master) approach is that we have a bunch of "semantically internal" stuff exposed as public. And this exposed stuff is what is giving many stylecop warnings and causing that EditorBrowsable discussion etc, right? (Even the Efl.Eo.Globals could be changed to something more restrictive like Efl.Eo.Internals?)

Sorry, I do not understand why would another assembly want to access EFL's internal types.
@YOhoho Can you give an usage example?

When third parties libraries want to use generated classes from eolian_mono(from .eo files), they need to access EFL#'s internal types. for example, you can produce compiler error with D10339.

Yeah, friendly assemblies let third party libraries access the target lib internals. But at the cost of recompiling the target library with the friendly info, right?


Regardless, I think we can start by not using the friendly assembly right away but using some patches in this stack together with patches like D10366 and D10365 to hide some not needed API items.

This way we can reduce the set of these "internal but must be public" to evaluate if we can live with some internal bits exposed - but nicely documented - or if there is enough items that we want to pay the cost of requiring recompilation with friendly assemblies.

lauromoura accepted this revision.Oct 28 2019, 1:45 PM
lauromoura added a subscriber: felipealmeida.

Well, reducing the exposed API could be quite complicated in the short term due to the complexity of the generated code.

After talking to @felipealmeida and @segfaultxavi, I think we could go ahead with this approach, as no other third-party library outside Tizen exists so far.

If the friendly assembly approach indeed happens to be too strict, we can re-expose the internal api in a clearner way in the future.

This revision is now accepted and ready to land.Oct 28 2019, 1:45 PM
Closed by commit rEFLe6fafe4e614e: mono: introduce friend assembly (authored by Yeongjong Lee <yj34.lee@samsung.com>, committed by lauromoura). · Explain WhyOct 28 2019, 4:26 PM
This revision was automatically updated to reflect the committed changes.