A work proposal which has been voted on and accepted
Mon, Sep 16
If "inherited generated classes" are eo custom classes that inherited efl classes, internal will occur compiler error.
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
Fri, Sep 13
Thu, Sep 12
Mon, Sep 9
Resolved in D9816
Wed, Sep 4
It is confirmed that SA1402 is not mandatory but it is recommended.
I will ask the reporter who raised this issue in detail and I will let you know.
Tue, Sep 3
If actually needed, we could disable this rule for generated code and keep it only for the manual code.
This may be hard with meson. See my first comment on its limitations.
I totally understand. If it is hard on upstream with meson, then I consider that I run some script manually to generate directories and change the cs names only for Tizen.
Mon, Sep 2
The main issues of this task are as follows.
For now, I've removed the underscore of Evt_Args by ac99e2ac9410d5b2ef6225fa1aaaf9ffcd6578fb
Fri, Aug 30
Can we change this task name?
Wed, Aug 28
Tue, Aug 27
Just to be sure, we're talking about removing the I prefix from the EventArgs classes, no? This makes sense.
Trying to automatically convert eo event names to verbs in the past tense is going to be an nightmare :)
All events should already be like that (as shown in the list above), and the rest should be renamed in the eo file.
Would that be an option, @lauromoura? Are all users of these methods inside the same assembly?
You'd better use internal instead if you want to hide them.
Mon, Aug 26
If a method is meant to be used only by derived classes, shouldn't it be protected? What am I missing?
What's the issue with the current approach? it's not clear from the task description.
Thu, Aug 22
Wed, Aug 21
The interface name was added to the struct name in order to avoid collisions between event arg structures with the same name. Removing this prefix leads at least to the following clashes:
Here is a list of generated events from the C# files. (without the prefix).
We could try hiding them but AFAIR they should be public so inherited classes can use them.
Evt today comes from the name of the event. Related to T8163
This could be kinda tricky to do in a generic way. We may end up having to build a list of irregular verbs and their past tense in order to generate them.
We may encounter some difficulty generating the files in sub folders as a meson issue  limits the output of custom_target command to be placed in the same folder as it is called.
Jul 24 2019
Good news! DocFX already filters out methods with the [EditorBrowsable(EditorBrowsableState.Never)] attribute :)