On 11/28/2013 04:32 PM, Tom Hacohen wrote: > On 17/11/13 13:53, Yakov Goldberg wrote: >> 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. > > An important reminder I hope you are planning for: > Don't forget Eo has a concept of access levels (private, public, > protected, and custom ones - though you can drop custom support if you > really want to), don't forget to include syntax for that. > > Generally speaking, you need to make sure you can mimic the eo tests > using eolian. > AFAIK, we are not planning :) We will generate only wrappings, enums, class_desc, event_desc, ... Huh, need to think now... weekend :) > -- > Tom. > >
------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
