Page MenuHomePhabricator

csharp: Translate class names.
Needs RevisionPublic

Authored by felipealmeida on Dec 16 2019, 8:56 PM.

Details

Summary

This is a placeholder translation table when the C# class name deviates
from the C one in a more specific way, like Progressbar vs ProgressBar

As some of these classes are already stable, we can't easily change them in
C.

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 14985
Build 10316: arc lint + arc unit
lauromoura created this revision.Dec 16 2019, 8:56 PM
lauromoura requested review of this revision.Dec 16 2019, 8:56 PM
Jaehyun_Cho accepted this revision.Dec 16 2019, 10:11 PM
This revision is now accepted and ready to land.Dec 16 2019, 10:11 PM
Jaehyun_Cho requested changes to this revision.Dec 16 2019, 11:02 PM
Jaehyun_Cho added inline comments.
src/bin/eolian_mono/eolian/mono/name_helpers.hh
376

There is a typo here.
Scrolllbar -> Scrollbar

This revision now requires changes to proceed.Dec 16 2019, 11:02 PM

Is it possible to apply this scheme to other data types? (e.g. enum in .eo)

e.g. enum Efl.Ui.Scrollbar_Mode is defined in efl_ui_scrollbar.eo -> enum Efl.Ui.ScrollbarMode

segfaultxavi requested changes to this revision.Dec 16 2019, 11:52 PM
segfaultxavi added subscribers: bu5hm4n, zmike.

Can we discuss a bit more this whole idea of the translation table? I still don't like it.
This table complicates things for users that know both APIs (C and C#). Imagine somebody debugging a C# method and trying to set breakpoints in C functions.
What is worse, this includes us, the maintainers! We will need to memorize this table to know if progressbar translates to Progressbar or ProgressBar, and this will make development slower.

Also, we are trying to create a new, clean API, free from the problems from Legacy. Creating this table means that we start having "legacy unified names" which we don't like but we cannot change.

Additionally:

felipealmeida commandeered this revision.Dec 21 2019, 1:57 PM
felipealmeida edited reviewers, added: lauromoura; removed: felipealmeida.

I can add changes to apply to other types too. But we need to define if this is really needed. @segfaultxavi seems to be pretty convinced this is not a good idea.

Yeah, I still don't like this. Can we keep discussing it?

This table complicates things for users that know both APIs (C and C#). Imagine somebody debugging a C# method and trying to set breakpoints in C functions.
What is worse, this includes us, the maintainers! We will need to memorize this table to know if progressbar translates to Progressbar or ProgressBar, and this will make development slower.

Also, we are trying to create a new, clean API, free from the problems from Legacy. Creating this table means that we start having "legacy unified names" which we don't like but we cannot change.

That is a very good argument to which I agree.