So, as soon as "Ragel Strikes Back"
here is " Elm_Image" in Jeremy's format.
http://pastebin.com/xptFf6y0
Properties and Methods are as Jeremy described.
And in the end you can also find "implements" and "signals".
Just one suggestion: lets move "implements" content into "properties"
and "methods":
methods{
some_method {
...
};
Evas_Smart :: show;
};
...only some comments about properties.
If we want to override , only setter or getter we need to specify "set"
or "get".
If you have better ideas about syntax, please suggest.
properties{
some_prop {
...
};
Evas_Object :: color;
Evas_Object :: size :: set;
Evas_Object :: visibility :: get;
};
======================================
Some additional question.
Here is some part of ElmFileselector.eo file.
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 {
/*@ Set, programmatically, the currently selected file/directory in
the given file selector widget */
return Eina_Bool;
params {
in const char* path; /*@ */
};
};
selected_get {
/*@ Get the currently selected item's (full) path, in the given file
the given file selector widget */
return const char*;
params {
};
};
}
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.
"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*", ""]
}
]
},
We will generate Eo and C - legacy functions as they are 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 C++, python and other bindings will ignore ret in setters/getters and
use it as property:
fileselector.path = "/root/some/path/filename"
So the question is:
should we treat it like this, or leave it as methods?
Yakov.
------------------------------------------------------------------------------
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
