On Mon, 04 Nov 2013 17:42:13 +0200 Yakov Goldberg <yako...@samsung.com> said:

I have to say that once this is in json.. it's exactly as i expected. it's just
all strings and quotes.. everywhere. let me just start with the beginning:


{
  "name": "elm_genlist",
  "macro": "ELM_OBJ_GENLIST_CLASS",
  "inherits": [
    "elm_layout",
    "elm_interface_scrollable",
    "Clickable_Interface"
  ],
  "constructors": {},
  "properties": {
    "homogeneous": {
      "comment_set": "Enable/disable homogeneous mode.",
      "comment_get": "Get whether the homogeneous mode is enabled.",
      "parameters": [
        [
          "",
          "Eina_Bool",
          "homogeneous",
          ""
        ]
      ]
    },
...
    "decorated_item": {
      "comment": "Get active genlist mode item",
      "type": "ro",
      "parameters": [
        [
          "",
          "Elm_Object_Item*",
          "ret",
          ""
        ]
      ]
    },
...
  "methods": {
    "item_insert_before": {
      "comment": "Insert an item before another in a genlist widget",
      "parameters": [
        [
          "in",
          "const",
          "Elm_Genlist_Item_Class*",
          "itc",
          ""
        ],
        [
          "in",
          "const",
          "void*",
          "data",
          ""
        ],
...

could be less "all blue strings only" and:

class { elm_genlist
  inherits elm_layout, elm_interface_scrollable, Clickable_Interface;
  macro ELM_OBJ_GENLIST_CLASS;
  constructors {}
  properties {
    homogeneous(Eina_Bool homogenous) {
      //set  Enable/disable homogeneous mode.
      //get  Get whether the homogeneous mode is enabled.
    }
...
    ro decorated_item(Elm_Object_Item *ret) {
      // Get active genlist mode item.
    }
...
  methods {
    item_insert_before(in const Elm_Genlist_Item_Class *itc, in const void
*data) {
      // Insert an item before another in a genlist widget.
    }
...

c style is MUCH more compact, more like actual code, easier to read AND write,
less typing and bears a much closer resemblance to the actual code. just add
some type keyword markers like "ro", "in", "out" etc. and FAR FEWER "'s
everywhere.

> Here is autogenerated (a little prettyfied and shortened) example of eo 
> file.
> http://pastebin.com/ERQphzNk
> I'm using my own python code from eo_bindings, where I was parsing c/h 
> files to get all eo information.
> 
> Some explanations:
> "name" - class name from Eo class description. We check that it is unique.
> "inherits" - names of parent classes
> "constructors" - (actually it is a method, just put it into separate 
> section). Here you will meet only custom cunstructors.
>     here "win_constructor" is a name
>              "comment" - comment
>              parameters:    2d array
>             ["in","const","char*","name",""],
>                  direction, modifier, type, name, comment
>                 maybe modifier is not needed, (but I already parsed it)
> 
> Properties.
>     Property can be set/get; only set, only get; this is saved in "type" 
> field: "rw"(or no tag), "ro", "wo".
>     How do I determine the type? If all parameters are "in" for some 
> func which ends with "_set"
>     and are "out" for some func which ends with "_get" this will be 
> set/get property. If this condition fails, they will be methods.
> 
>     For set/get property comments are saved in "comment_set" / "comment_get"
>     For set property comments are saved in "comment" or "comment_set"
>     For get property comments are saved in "comment" or "comment_get"
>     Direction is not saved for property's parameters.
> 
> Methods: the same as properties, but with direction of parameter.
> 
> Implements: list of overloaded functions:
>               ["class name" , "func_name", "func_type"]
> Some comments: We need to have "func_type" here.
> suppose we have func "color" and property "color" in parent class,
> and want to overload color_set property in child class, so we will have:
> ["parent_class", "color", "set"]
> 
> "signals" - it's easy, if all events will work only through eo we need 
> only "event_name" and "description"
> 
> Also, here you can find Genlist Eo file.
> http://pastebin.com/w26g33ZP  :))
> It's not prettified, because I simply dump python structures into the json.
> All these autogenerated files are only for initial generation, and are 
> needed to be checked manually.
> 
> 
> On 10/21/2013 08:29 PM, daniel.za...@samsung.com wrote:
> > 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
> >
> >
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from the latest Intel processors and coprocessors. See abstracts and
> > register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/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=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&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