Hello,
On Fri, Nov 1, 2013 at 12:21 AM, Tom Hacohen <tom.haco...@samsung.com> wrote:
> On 21/10/13 18:29, daniel.za...@samsung.com wrote:
>> I would like to discuss about a project that we are beginning just now.
>> I presented it on EFL dev. day yesterday but I would like to share it
>> here since it will imply all the EFL developers (yes, you) one day or
>> another.
>>
>> It is called Eolian and was first aimed to facilitate addition of new Eo
>> functions by auto-generating code. Then we noted that we can
>> automatically generate language bindings too but it is not the goal of
>> this discussion.
>>
>> The idea is that each Eo class is represented into a .eo file. These
>> files are manually modified to add new functions, comments, callbacks...
>> and parsed and the generation phase updates the C/H files.
>>
>> They contain descriptions of inherited classes, properties, methods,
>> base classes implemented functions and callbacks.
>>
>> We thought about two formats:
>> - a C-like format:
>> Evas_Object_Image =
>> {
>> inherit
>> {
>> Evas_Object;
>> }
>> properties
>> {
>> /* Set the DPI resolution ... */
>> load_dpi(double dpi /* dpi resolution*/);
>> /* Apply the source object's clip to the proxy */
>> source_clip(Eina_Bool source_clip);
>> /* Set whether the image object's fill property ... */
>> filled(Eina_Bool filled);
>> /* Get the kind of looping the image object does. */
>> ro animated_loop_type(
>> Evas_Image_Animated_Loop_Hint hint /* hint */
>> );
>> /* Get the number times the animation of the object loops. */
>> ro animated_loop_count(
>> int loop_count
>> );
>> }
>> methods
>> {
>> /* Set the source object… */
>> source_set(
>> in Evas_Object* src /* in */,
>> out Eina_Bool* result /* out */
>> );
>> /* Get the current source object ... */
>> source_get(
>> out Evas_Object** src /* out */
>> );
>> /* Begin preloading an image … */
>> preload_begin();
>> /* Mark a sub-region of the given ... */
>> data_update_add(
>> in int x /* in */,
>> in int y /* in */,
>> in int w /* in */,
>> in int h /* in */
>> );
>> }
>> }
>>
>> For C developers that we are, it has the advantage to be easier to our
>> eyes. It fits most of the needs but still lacks for specific points:
>> - if we have a property whose comment is different for set and get, how
>> can we describe it? By inserting "tokens" inside the comments
>> themselves, meaning parsing of the comments is needed.
>> - if we want to define a function as virtual pure, do we use the so
>> loved C++ notation "= 0"?
>> - properties that are read-only or write-only (only get or set): do we
>> add some ro/wo parameter, as in the example?
>> ...
>> People complained that it seems too much like C++.
>>
>> - JSON format:
>> {
>> "class_name" : "Evas_Object_Image",
>> "inherits" : [ "Evas_Object" ],
>> "properties" : [
>> {
>> "name" : "load_dpi",
>> "description" : "DPI resolution ...",
>> "parameter" : [
>> {
>> "name" : "dpi",
>> "type" : "double",
>> "description" : "dpi resolution"
>> }
>> }
>> ... (don't have the force to write all ;-)
>> }
>> The format is less intuitive to C developers and there is more to write
>> but it is extensible and so easily solves the issues described in the
>> C-style.
>>
>> So, until yesterday (the day I presented), I really thought we would go
>> on the C (ok, C++) style but now that I saw some faces when I showed the
>> C format and since I want to come back home safe, I prefer asking here.
>>
>
> First of all, thank you Daniel for communicating your changes here. I
> think that Eolian has the potential to be an important foundation in the
> future of the EFL, so it's really important that it's good.
>
> Haven't read the whole thread yet, but there are a few comments I have
> to make:
> 1. A vote means nothing, we shouldn't go with something just because
> people prefer one buzzword over the other.
> 2. As raster has said, saying "we also have the parser ready for this"
> is like saying nothing. The "language" is in the strings themselves, not
> the few delimiters.
>
> I personally agree with raster, however I do prefer json in general. The
> question is: can me make something that works for us with json? The
> answer might be yes, might be no, needs to be evaluated, not arbitrarily
> voted on.
>
> Daniel: I think the main thing to see is how to make the best syntax.
> C(++?)-style, json or whatever. I would prefer something that is already
> well-defined like the structure that json provides, but maybe there
> involve a C-like syntax, so something more like:
>
> {
> "class_name" : "Evas_Object_Image",
> "inherits" : [ "Evas_Object" ],
> "properties" : [
> "load_dpi(double dpi)",
> "source_clip(Eina_Bool source_clip)",
I think that the following is more readable :
"properties" : [
"load_dpi": [ "dpi": "double" ],
"source_clip" : [ "source_clip": "Evas_Object" ],
"position" : [ "x" : "int", "y" : "int" ]
]
Also we need to define events and the associated data they will be
given. That is something missing until now in both description. I
would think that JSON as some advantage here as we can do something
like :
"events" : [
"EO_EV_CALLBACK_ADD" : { [ { "name" : "const char *", "doc" : "const
char *", "unfreezable" : "Eina_Bool" } ] },
"EVAS_CANVAS_RENDER_FLUSH_PRE" : { }
]
Or something like that.
> I'm not sure. I just think this should be discussed and evaluated as
> it's of supreme importance. It should definitely not be overly cubersome
> and complicated to work with, as that's what people will write in. Also,
> it must support comments.
I agree with you that we need to explore the full syntax before voting
on what we do prefer. As we could do a stupid JSON where the value are
directly the C function (that should theoretically had satisfied both
side being C and JSON, but would result in an uglier result). So lets
try to see what we can come with.
--
Cedric BAIL
------------------------------------------------------------------------------
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
