Re: [E-devel] Eolian meta-data parsing

[Lucas De M. <luc...@pr...>]

On Tue, Oct 22, 2013 at 3:03 PM, Leif Middelschulte
<lei...@gm...> wrote:
> 2013/10/21 dan...@sa... <dan...@sa...>:
>> Hi all,
>>
>> 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.
>>
>> Thank you for your help
>> JackDanielZ, alias Daniel Zomething
>
> Do you want something you'd only write in the text editor?
> If that's not a restriction, have you thought about using UML class
> diagrams? I'm not sure about inlining comments in it, but it has all
> the other features and is XML, so trivially transformable and
> validateable.


nooooooooooooooooooooooooo


+1 for json


Lucas De Marchi