Menu
▾
▴
Re: [E-devel] Eolian meta-data parsing, episode 2
|
From: <dan...@sa...> - 2013-12-31 08:05:58
|
On 12/31/2013 08:00 AM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 05 Dec 2013 14:12:21 +0200 Yakov Goldberg <ya...@sa...> said:
>
>> Hi guys,
>>
>> we have some additional question.
>> Here is some part of ElmFileselector.eo file. (Still in JSON)
>> You can see "selected_set" and "selected_get" are described, as methods.
>> Why? Because I generate, this eo file, by parsing descriptions of eo
>> classes.
>> If there are two functions which have:
>> - the same name with "set/get" suffix;
>> - the same number of parameters;
>> - all parameters are "in" for "set"
>> - all parameters are "out" for "get"
>> it will be described as property; (or "only_set"/"only_get" property)
>> if one of these rules fails, functions will be generated as methods.
>>
>> Because of legacy, "selected_set" func returns, so here I generate it as
>> method.
>>
>> "methods": {
>> "selected_set": {
>> "comment": "Set, programmatically, the currently selected
>> file/directory in the given file selector widget",
>> "return_type": "Eina_Bool",
>> "parameters": {
>> "in": [
>> { "path": [ "const char*", "" ] }
>> ]
>> }
>> },
>> "selected_get": {
>> "comment": "Get the currently selected item's (full) path, in the
>> given file the given file selector widget",
>> "return_type": "const char*",
>> "parameters": {}
>> },
>> }
>>
>> But maybe, as soon as it is almost property (only one "ret" gets in the
>> way here), we can describe it as property, which returns some value.
>> So we will generate Eo and C - legacy functions as they are now. And
>> C++, python and other bindings will use this as property, but will
>> ignore ret in setters/getters.
>>
>> "selected": {
>> "set": {
>> "return" : "Eina_Bool",
>> "comment": "Set, programmatically, the currently selected
>> file/directory in the given file selector widget"
>> },
>> "get": {
>> "comment": "Get the currently selected item's (full) path, in
>> the given file the given file selector widget"
>> },
>> "parameters": [
>> {
>> "path": ["const char*", ""]
>> }
>> ]
>> },
>> so in this case we will generate, as it is right now:
>> eo macro: "selected_set" EO_TYPECHECK (path, const char*) EO_TYPECHECK
>> (ret, Eina_Bool *)
>> eo macro: "selected_get" EO_TYPECHECK (path, const char**)
>> legacy: Eina_Bool elm_fileselector_selected_set(Eo * obj, const char* path)
>> legacy: const char * elm_fileselector_selected_get(Eo * obj)
>>
>> and in bindings we can ignore return, and use it as usual property:
>> fileselector.path = "/root/some/path/filename"
>>
>> So the question is:
>> should we treat it like this, or leave it as methods?
> i like it being a property. remember this is just an auto-conversion step to
> convert current eo stuff to eo2... for eolian and eo files - this is simpoly an
> intermediate step of getting eo solid and workable.
>
> we STILL have to go back and redo classes and methods from the ground up for
> efl2 and that's going to basically be manual no matter what.
Great, that's the way we chose :-)
>
>> Yakov.
>>
>>
>> On 11/17/2013 03:53 PM, 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.
>>>
>>> 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
>>> enl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> enlightenment-devel mailing list
>> enl...@li...
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
|