- Hiding unnecessary APIs
- Now : many interop related APIs has public visibility e.g. efl_ui_win_wm_available_rotations_set_ptr
- Suggested : many interop related APIs has private visibility e.g. efl_ui_win_wm_available_rotations_set_ptr
Description
Details
- Differential Revisions
- D10102: csharp: Hide internal stuff from editors.
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T7356 EO: Support elm_config APIs | ||
Open | felipealmeida | T7204 Discussion about C# binding syntax | ||
Open | brunobelo | T8165 C#: Hide unecessary API |
We could try hiding them but AFAIR they should be public so inherited classes can use them.
What if we use [EditorBrowsable(EditorBrowsableState.Never)] to hide them from the editor?
If a method is meant to be used only by derived classes, shouldn't it be protected? What am I missing?
I don't like hiding it from the editor since it won't show up for writers of derived classes.
I actually meant "inherited generated classes". No regular C# user (even overriding methods) will be using them.
Would that be an option, @lauromoura? Are all users of these methods inside the same assembly?
If "inherited generated classes" are eo custom classes that inherited efl classes, internal will occur compiler error.
e.g.
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(83,80): error CS0122: `Efl.PartConcrete.NativeMethods.efl_part_get_ptr' is inaccessible due to its protection level
With this patch
diff --git a/src/bin/eolian_mono/eolian/mono/function_definition.hh b/src/bin/eolian_mono/eolian/mono/function_definition.hh index a0f28df..149272a 100644 --- a/src/bin/eolian_mono/eolian/mono/function_definition.hh +++ b/src/bin/eolian_mono/eolian/mono/function_definition.hh @@ -61,7 +61,7 @@ struct native_function_definition_generator if(!as_generator ( indent << eolian_mono::marshall_annotation(true) << "\n" - << indent << "public delegate " + << indent << "internal delegate " << eolian_mono::marshall_type(true) << " " << string << "_api_delegate(" << (f.is_static ? "" : "System.IntPtr obj") @@ -76,7 +76,7 @@ struct native_function_definition_generator // Delegate holder (so it can't be collected). if(!as_generator - (indent << "public static Efl.Eo.FunctionWrapper<" << string << "_api_delegate> " << string << "_ptr = new Efl.Eo.FunctionWrapper<" + (indent << "internal static Efl.Eo.FunctionWrapper<" << string << "_api_delegate> " << string << "_ptr = new Efl.Eo.FunctionWrapper<" << string << "_api_delegate>(Module, \"" << string << "\");\n\n") .generate(sink, std::make_tuple(f.c_name, f.c_name, f.c_name, f.c_name), context)) return false; diff --git a/src/bin/eolian_mono/eolian/mono/function_pointer.hh b/src/bin/eolian_mono/eolian/mono/function_pointer.hh index 721368f..f4378d1 100644 --- a/src/bin/eolian_mono/eolian/mono/function_pointer.hh +++ b/src/bin/eolian_mono/eolian/mono/function_pointer.hh @@ -51,7 +51,7 @@ struct function_pointer { return false; // "Internal" delegate, 1-to-1 with the Unamaged function type if (!as_generator(marshall_annotation(true) - << "public delegate " << marshall_type(true) << " " << string // public? + << "internal delegate " << marshall_type(true) << " " << string << "Internal(IntPtr data" << *grammar::attribute_reorder<-1, -1>((", " << marshall_annotation << " " << marshall_parameter)) << ");\n") .generate(sink, std::make_tuple(f.return_type, f.return_type, f_name, f.parameters), funcptr_ctx))
Yeah, I'm referring to eolian-generated classes that go in other assemblies, like the test suite.
Generated classes sometimes may refer to these methods, like when implementing an interface, where it accesses the SomeInterfaceConcrete.NativeMethods.some_method_ptr. That is why they can't be always protected/internal and must be kept public (although already in a "reserved" namespace/class, like that NativeMethods).