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