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".
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"]
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.
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
