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 appreciated and I'm happy to answer any questions that arise.

Regards,
-- 
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=65839951&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to