Re: [E-devel] Eo API change and C++ binding
On 28/10/13 22:17, Felipe Magno de Almeida wrote:
Hello all,
I'm working on an Eo API change for EFL. We're working on top of
Jérémy Zurcher's eo2 branch.
The problem with creating Eo API with the current Eo or with eo2 is
that information about a Eo class becomes inevatibly scattered and
adds a lot of redudancy. For example in eo1 there's the need to write
macros that check the signature, fill Eo_Op_Description array; for eo2
there's the need to use the EO2_OP_FUNC_* macros to define the API
functions, still fill Eo2_Op_Description array, cast the Private_Data,
etc.
We needed a way to create Eo classes that had more expressiveness. So
that it becomes possible to read a Eo class and know how many
functions it has, their signatures, etc (this is to create a C++
binding generated by a tool, I'll get to this later).
So we started working on a more expressive way to define Eo classes
and we've implemented it. (Still lacks documentation and tests which
are scheduled for november). The new API makes use of two sets of
macros: EO3_DECLARE_* and EO3_DEFINE_*. These macros generate, through
the CPP, the boilerplate code that is required for Eo classes, such as
API functions (those that get called through eo2_do and route to the
correct implementation function), event functions with specific
signatures, etc.
These macros declare and define the class, respectively, and are meant
to be used in headers and .c files. These macros allow us to have a
good expressiveness for defining Eo classes without moving away from C
and while eliminating a lot of boilerplate code.
So, one Eo class example using this API:
https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo3_simple.h
#define EO3_SIMPLE_CLASS eo3_simple \
, constructor(simple_constructor, _constructor, int) \
, destructor(_destructor)\
, function(simple_inc, _inc, void) \
, function(simple_get, _get, int)\
, function(simple_set, _set, void, int) \
, function(simple_virtual, _set, void, int) \
, class_function(simple_class_foo, _class_hello, void, int) \
, event(simple_set, int)
https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo3_simple.c
typedef struct
{
int x;
} Private_Data;
static void _inc(Eo *objid EINA_UNUSED, Private_Data* self)
{
printf(eo3_simple::inc %d-%d\n, self-x, self-x+1);
self-x += 1;
}
static int _get(Eo *objid EINA_UNUSED, Private_Data* self)
{
printf(eo3_simple::get %d\n, self-x);
return self-x;
}
static void _set(Eo *objid, Private_Data* self, int x)
{
eo2_do(objid, simple_set_callback_call(x));
printf(eo3_simple::set %d\n, x);
self-x = x;
}
// [ other functions ]
EO3_DEFINE_CLASS(EO3_SIMPLE_CLASS, ((EO3_BASE_CLASS)), Private_Data)
===
Which compared to eo2:
https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo2_simple.c
https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo2_simple.h
Or eo1:
https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo_simple.c
https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo_simple.h
Is much easier to use.
Now to the C++ binding. This API modification to Eo is meant to make
defining Eo classes expressive enough that a tool can be used to
generate bindings automatically for other languages, specially C++.
The tool that will generate the C++ binding will read the header files
and with a CPP library it wil hook on EO3_DEFINE_* and EO3_DECLARE_*
to read the class informations. This part of the tool will be written
as a C++ library to be reused for other bindings to get the necessary
information for the EFL API through its headers.
Eolian is also being developed by JackDanielZ that gives
expressiveness for defining Eo classes by using another language and
tool that generates the headers and C files. The C++ binding
generating tool can easily be made to read both formats to generate
the binding.
However, I feel that this Eo API modification has its merits for
whoever might want to use C directly to develop in EFL which I think
is a great plus and here I'm advocating that this goes upstream so we
can go forward with a C++ binding for EFL.
There are other examples of the API in
https://github.com/expertisesolutions/efl/tree/eo3/eo2test . All files
that start with eo3_*.
Also, we have the examples that specify how the C++ generated binding
tool will output the generated files from this EO API (or the .eo
files) at
https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx/generated
with usage samples at
https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx/samples
and some utilitary headers at
https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx
Any criticism is
Re: [E-devel] Eo API change and C++ binding
Hi Felipe, I think Cedric told you but we have a project for the boilerplate that is called Eolian. You describe a Eo class in JSON format (at least for the moment according to the vote that was in the ml) and then can generate the EO1/2 API functions, legacy functions, classes information in live access and bindings. So I think your project and ours are just overlapping and will create more issues than help everyone. What I understood is that you had to create all the Eina types in C++ and a few examples of the classes in C++ and we take your work and generate it from our meta-data. Please update me. Thank you Daniel (JackDanielZ) On 10/29/2013 01:17 AM, Vinícius dos Santos Oliveira wrote: Em Seg, 2013-10-28 às 21:03 -0200, Felipe Magno de Almeida escreveu: Also, The C++ binding is not just the generated headers, there is going to be a EINA-specific C++ API and more classes that will help with MVC and other helpful abstractions that aren't attainable with generated code. The generated C++, though, gives a type-safe layer and makes evolution easier and safer as EFL evolves. If good documentation is written, then I'll want to use EFL++ instead of Qt in my now-stalled bomberman-like game somewhere in the future. I hope you succeed with this work. =) -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API change and C++ binding
Em Seg, 2013-10-28 às 20:17 -0200, Felipe Magno de Almeida escreveu: The tool that will generate the C++ binding will read the header files and with a CPP library it wil hook on EO3_DEFINE_* and EO3_DECLARE_* to read the class informations. This part of the tool will be written as a C++ library to be reused for other bindings to get the necessary information for the EFL API through its headers. Please don't! Please don't make the same mistake of Qt developers. Don't write yet another preprocessing tool. At least, if you are going to write such a tool, write a complete parser that will never have any trouble with #defines and newer syntax and you're willing to maintain it... But... how will your tool know the defines and such things? Probably I'll have to change my build system to call your tool using the same compiler args... I think you're aware that GTK-- is winning from Qt among some C++ developers, because GTK-- is more C++ish than Qt (thanks to moc and other things). -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker signature.asc Description: This is a digitally signed message part -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API change and C++ binding
Hello Vinicius, On Mon, Oct 28, 2013 at 8:48 PM, Vinícius dos Santos Oliveira vini.ipsma...@gmail.com wrote: Em Seg, 2013-10-28 às 20:17 -0200, Felipe Magno de Almeida escreveu: The tool that will generate the C++ binding will read the header files and with a CPP library it wil hook on EO3_DEFINE_* and EO3_DECLARE_* to read the class informations. This part of the tool will be written as a C++ library to be reused for other bindings to get the necessary information for the EFL API through its headers. Please don't! Please don't make the same mistake of Qt developers. Don't write yet another preprocessing tool. At least, if you are going to write such a tool, write a complete parser that will never have any trouble with #defines and newer syntax and you're willing to maintain it... But... how will your tool know the defines and such things? Probably I'll have to change my build system to call your tool using the same compiler args... I think you're aware that GTK-- is winning from Qt among some C++ developers, because GTK-- is more C++ish than Qt (thanks to moc and other things). We're not creating a preprocessing tool as moc. The tool is just used to generate C++ classes from C, so that we have C++ classes that we can inherit, instantiate and call with a C++ familiar syntax. It will not be required in the build system for C++ applications. Just run it before installing EFL and install the generated headers for C++ EFL and #include them and use them. And yes, I agree, moc is terrible. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker -- Felipe Magno de Almeida -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API change and C++ binding
Also, The C++ binding is not just the generated headers, there is going to be a EINA-specific C++ API and more classes that will help with MVC and other helpful abstractions that aren't attainable with generated code. The generated C++, though, gives a type-safe layer and makes evolution easier and safer as EFL evolves. On Mon, Oct 28, 2013 at 8:55 PM, Felipe Magno de Almeida felipe.m.alme...@gmail.com wrote: Hello Vinicius, On Mon, Oct 28, 2013 at 8:48 PM, Vinícius dos Santos Oliveira vini.ipsma...@gmail.com wrote: Em Seg, 2013-10-28 às 20:17 -0200, Felipe Magno de Almeida escreveu: The tool that will generate the C++ binding will read the header files and with a CPP library it wil hook on EO3_DEFINE_* and EO3_DECLARE_* to read the class informations. This part of the tool will be written as a C++ library to be reused for other bindings to get the necessary information for the EFL API through its headers. Please don't! Please don't make the same mistake of Qt developers. Don't write yet another preprocessing tool. At least, if you are going to write such a tool, write a complete parser that will never have any trouble with #defines and newer syntax and you're willing to maintain it... But... how will your tool know the defines and such things? Probably I'll have to change my build system to call your tool using the same compiler args... I think you're aware that GTK-- is winning from Qt among some C++ developers, because GTK-- is more C++ish than Qt (thanks to moc and other things). We're not creating a preprocessing tool as moc. The tool is just used to generate C++ classes from C, so that we have C++ classes that we can inherit, instantiate and call with a C++ familiar syntax. It will not be required in the build system for C++ applications. Just run it before installing EFL and install the generated headers for C++ EFL and #include them and use them. And yes, I agree, moc is terrible. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker -- Felipe Magno de Almeida -- Felipe Magno de Almeida -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API change and C++ binding
Em Seg, 2013-10-28 às 20:55 -0200, Felipe Magno de Almeida escreveu: We're not creating a preprocessing tool as moc. The tool is just used to generate C++ classes from C, so that we have C++ classes that we can inherit, instantiate and call with a C++ familiar syntax. It will not be required in the build system for C++ applications. Just run it before installing EFL and install the generated headers for C++ EFL and #include them and use them. That looks interesting. So we wouldn't need several C++ developers to maintain the C++ port. All conversion would be automatic. One code base to maintain is always better. :) -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker signature.asc Description: This is a digitally signed message part -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo API change and C++ binding
Em Seg, 2013-10-28 às 21:03 -0200, Felipe Magno de Almeida escreveu: Also, The C++ binding is not just the generated headers, there is going to be a EINA-specific C++ API and more classes that will help with MVC and other helpful abstractions that aren't attainable with generated code. The generated C++, though, gives a type-safe layer and makes evolution easier and safer as EFL evolves. If good documentation is written, then I'll want to use EFL++ instead of Qt in my now-stalled bomberman-like game somewhere in the future. I hope you succeed with this work. =) -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker signature.asc Description: This is a digitally signed message part -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
