17.11.2013 15:53, Yakov Goldberg kirjoitti:
> Hi all :)
>
> I'd like to start new thread on discussion of Eo format.
>
> Short memo about a project:
> 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.
>
> 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 constructors.
>
> Properties.
> Property can be set/get; only set, only get; this is saved in "type"
> field: "rw"(or no tag), "ro", "wo".
Have you thought about adding another level of nesting with set and get
members? This way you could make them optional and wouldn't need that
type field:
...
"properties": {
"size_hint_max": {
"set": {
"comment": "Sets the hints for an object's maximum size.",
"legacy_override": "evas_object_size_hint_max_set"
},
"get": {
"comment": "Retrieves the hints for an object's maximum size.",
"legacy_override": "evas_object_size_hint_max_get"
},
"parameters": [
{"w" : ["Evas_Coord", "comment"]},
{"h" : ["Evas_Coord", "comment"]}
]
},
"below": {
"get": {
"comment": "Get the Evas object stacked right below the object",
"legacy_override": "evas_object_below_get"
},
"parameters": [
{"ret" : ["Evas_Object*", "comment"]},
]
}
...
Another suggestion is to make legacy_override apply the whole class as a
prefix:
{
"name": "Evas_Image",
"legacy_prefix": "evas_object_image",
...
You could have the individual legacy overrides for cases where legacy
property/method name does not follow the naming in Eo API, in cases
where there is no legacy prop/method you could have an empty string as
override, or maybe a bool value:
"legacy": false
In the Python bindings we've also got "deleters" for properties; for
example when user calls del(list.children) it's the same as calling
clear() on the list. Would you consider having these deleters in Eo
metadata as well?
> Methods: the same as properties, but with direction of parameter.
>
> Implements: list of overridden functions:
> ["class name" , "func_name"]
> Sometimes, if there will be name clash between property and method, user will
> have to add 3rd paremeter "func_type":
> ["class name" , "method_name", "method_type"]
Why is this third parameter needed? Wouldn't it be easier to forbid
clashing properties/methods and have a cleanly overriding inheritance?
>
>
> Example.
> http://pastebin.com/u9DPnmK2
>
> Some issue.
> One of the main task is to generate legacy functions. But not every Eo
> function has a legacy. So we have to add
> "legacy"("legacy_override") flag into JSON. Moreover there are cases
> when we need to specify legacy func's name.
>
> Example: Eo class name is "Evas_Image". It has a method "source_set".
> (This is not a property, because it returns some value)
> To generate legacy we take class name and method name, so we will get
> "evas_image_source_set", while real name is "evas_object_image_source_set"
> Thus, as soon as we have to keep "legacy" flag, we can keep full name of
> legacy method.
>
> {
> "name": "Evas_Image",
> "inherits": ["Evas_Object"],
> "methods" : {
> "source_set": {
> "comment": "Set the source object on an image object.",
> "return_type": "Eina_Bool",
> "legacy_override": "evas_object_image_source_set",
> "parameters": {
> "in" : [
> {"src" : ["Evas_Object*", "comment"]}
> ]
> }
> },
> }
> }
>
>
> - In case of properties, we need to keep "legacy_set", "legacy_get".
> Initial generation will be automatic, nevertheless we'll have to check
> everything manually.
> - Description of parameters: {"name" : ["type", "comment"]}; for
> methods additional sections "in" "out" must be added.
>
> - implements section can be moved into methods and properties sections.
> It can look more consistent, but requires one more nested level.
> "methods" :
> { "realizes" : {
> "source_set" : {
> }
> },
> "implements" : [
> ["Evas_Smart", "resize"]
> ]
> }
>
> - implements section should have description of event being sent
> "implements": [
> ["Evas_Smart", "resize", {"int", "int", "char *"}],
> ]
> ========================================================
> ========================================================
> Another solution is to write C-styled eo file. Which requires another
> parser.
> http://pastebin.com/stycZmKV
> This is very first version, after which we switched to JSON, so it
> doesn't have many fields.
>
> So advantages and drawbacks:
> - C-styled file is more compact
>
> - JSON is more flexible and scalable (we already require several helping
> tags and different comments for _set/_get properties)
> and also some reference between functions(for documentation) need to
> be added.
> - easier to support versioning
> - 3rd party parsers can be used.
> but requires to keep JSON structure - that means quotes and brackets.
Have you looked into YAML?
https://en.wikipedia.org/wiki/YAML
It has similar features to JSON while being more compact.
If the choice is between C-like syntax and JSON, I'll go with JSON as
it's easier to create a forward compatible parser/lexer for it, and
because of the reasons you mentioned above. But this should not depend
on a single round of voting, we should strive to find a syntax and
structure which serves all our relevant needs and is easy to work with.
P.S. I am interested to work on the language bindings aspect of this
after 1.8 Python bindings are released.
>
> Mixing them is not good idea.
>
> I'll be glad to hear your comments.
>
> Yakov
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
