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?
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
> enlightenment-devel@lists.sourceforge.net
> 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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
