AFAIU
. is for namespace
_ is to join multiple words
Example: Efl.Net.Ip_Address that should generate efl::net::IpAddress
or something like that in C++
From conr2d's email I believe it should be Internal_Part
On Mon, Dec 19, 2016 at 12:42 AM, Jean-Philippe André <j...@videolan.org> wrote:
> Hi Conr2d,
>
> On 18 December 2016 at 21:46, Conrad Um <con...@gmail.com> wrote:
>
>> Dear all,
>>
>> As I mentioned in previous mail, I'm writing a Vala binding generator, but
>> I found our naming rule for namespaces a litte awkward. That is, we connect
>> all tokens in namespace with period, it seems to be not appropriate in
>> meaning of namespace.
>>
>> For example, "Elm.Layout" and "Elm.Layout.Internal.Part', they can be
>> translated like the next.
>> namespace Elm { *class Layout* { namespace Internal { *class Part *{} } } }
>>
>> Nested namespace "Internal" cannot be put under class in Vala. It can be
>> just a limitation in specific programming language, but even in eolian_cxx,
>> they are translated into the next.
>> namespace elm { *class Layout* {} }
>> namespace elm { namespace layout { namespace internal { *class Part* {} } }
>> }
>>
>> It seems to be used mixed upper and lower case name in namespaces to avoid
>> above namespace conflict issue. However, I think "Elm.Layout.Internal.Part"
>> should be able to access the parent class' ("Elm.Layout" in this case)
>> protected members, so it should be placed in "Elm.Layout" class block.
>> (Of course, I know in our "C" file, we only need to put #define
>> XXX_PROTECTED in the top of the file to access protected members.)
>>
>> To solve this problem, "Elm.Layout.Internal.Part" can be named as
>> "Elm.Layout.Internal_Part", and its translation will be:
>> namespace Elm { *class Layout* { *class Internal_Part* {} } }
>>
>> This can be done by binding generator, but I think that well-arranged eo
>> namespaces can make the binding writers approach Eo system with familiar
>> perspective.
>
>
> Yeah that's a good point.
> We will definitely have to review our final EO class names before releasing
> the API anyway.
>
> We are currently using both _ and . in various places, without any clear
> rule.
>
> --
> Jean-Philippe André
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
