24.11.2013 11:34, Yakov Goldberg kirjoitti:
> Hi again!
> Kai, Cedric thanks for answer!
> Comments added.
>
> On 11/22/2013 04:20 AM, Cedric BAIL wrote:
>> On Fri, Nov 22, 2013 at 12:27 AM, Kai Huuhko <kai.huu...@gmail.com> wrote:
>>> 17.11.2013 15:53, Yakov Goldberg kirjoitti:
>>>> 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".
>>> Have you thought about adding another level of nesting with set and get
>>> members? This way you could make them optional and wouldn't need that
>>> type field:
>>>
>>> ...
>>> "properties": {
>>> "size_hint_max": {
>>> "set": {
>>> "comment": "Sets the hints for an object's maximum size.",
>>> "legacy_override": "evas_object_size_hint_max_set"
>>> },
>>> "get": {
>>> "comment": "Retrieves the hints for an object's maximum size.",
>>> "legacy_override": "evas_object_size_hint_max_get"
>>> },
>>> "parameters": [
>>> {"w" : ["Evas_Coord", "comment"]},
>>> {"h" : ["Evas_Coord", "comment"]}
>>> ]
>>> },
>>> "below": {
>>> "get": {
>>> "comment": "Get the Evas object stacked right below the object",
>>> "legacy_override": "evas_object_below_get"
>>> },
>>> "parameters": [
>>> {"ret" : ["Evas_Object*", "comment"]},
>>> ]
>>> }
>>> ...
>> That sounds like a nice improvement to me.
> Same for me. I'll play with it.
>>
>>> Another suggestion is to make legacy_override apply the whole class as a
>>> prefix:
>>>
>>> {
>>> "name": "Evas_Image",
>>> "legacy_prefix": "evas_object_image",
>>> ...
>>>
>>> You could have the individual legacy overrides for cases where legacy
>>> property/method name does not follow the naming in Eo API, in cases
>>> where there is no legacy prop/method you could have an empty string as
>>> override, or maybe a bool value:
>>>
>>> "legacy": false
>> Then why not just: "legacy" instead of "legacy_prefix", and if not
>> defined, there is no legacy function provided by that class.
> Yes, lets put "legacy" property per class. Just there will be some
> redundancy,
> for class "Elm_Button" we will have to provide "legacy" : "elm_button".
> It can be deleted starting from some version. (I also have to add some
> "version" tag)
>
> There is also one more question.
> Now we have legacy: "elm_button_autorepeat_get"
> also we have added Eo API
> "elm_obj_button_autorepeat_get".
> Will Eo2 API be the same -> "elm_obj_button_autorepeat_get"?
>>> In the Python bindings we've also got "deleters" for properties; for
>>> example when user calls del(list.children) it's the same as calling
>>> clear() on the list. Would you consider having these deleters in Eo
>>> metadata as well?
>> That is a very good idea indeed. Javascript binding will benefit from
>> the same metadata.
> Yea, cool. But I want to clear something.
> Suppose we have Evas_Object class and funcs to set/get color.
> So in python we will have EvasObject_Py class with setter/getter,
Yes
> but without deleter, as there is no color property in object actually.
There isn't? Did you mean there is no color_del method? I'm confused.
> So we will not provide deleter in eo-mata in this case.
Correct
> Smth like this:
>
> class EvasObject_Py(object):
>
> def getcolor(self):
> cdef int r, g, b, a
> eo_do(self.eo_obj, evas_obj_color_get(&r, &g, &b, &a))
> r_ = r
> g_ = g
> b_ = b
> a_ = a
> return (r_, g_, b_, a_)
> def setcolor(self, r, g, b, a):
> eo_do(self.eo_obj, evas_obj_color_get(r, g, b, a))
>
> color = property(getcolor, setcolor, None, "I'm the 'color'
> property.")
>
>
> Now about lists:
> AFAIR, in Py_Bindings some data is saved in internal lists sometimes.
> So this could look like this:
>
> class SomeClass(object):
> def __init__(self):
> self._somelst = []
>
> def getsomelst(self):
> return self._somelst
> def setsomelst(self, lst):
> self._somelst = lst
> cdef Eina_List _lst
> # casting from py list to Eina_List
> eo_do(self.eo_obj, some_class_somelist_set(_lst))
> def delsomelst(self):
> del self._somelst
> eo_do(self.eo_obj, some_class_somelist_clear())
> somelst = property(getsomelst, setlsomest, delsomelst, "I'm the
> 'lst' property.")
>
> So in eo-meta we can provide func "somelist_clear" as a deleter?
> Did I understand right?
I didn't mean Python lists, I meant for example containers in EFL/Elm,
such as Evas Box and Elementary List, that have methods children_get and
clear.
In this case children_get() is the getter, and clear() the deleter.
It would be possible to add a setter there as well, that clears the list
and adds child objects from the list argument passed to it, but that is
more implementation specific so maybe out of scope of any automated
metadata.
There are other examples where deleters exist such as the unset()
methods in elm_object.h
>
>>>> 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"]
>>> Why is this third parameter needed? Wouldn't it be easier to forbid
>>> clashing properties/methods and have a cleanly overriding inheritance?
> Great, you are right!
> In this case (in Python) we will have two definitions for "some_name" in
> class.
> One will defined as function and other as property, but only one(which
> is defined last) will work.
> Am I right?
> And this means that
> "elm_widget_theme"
> "elm_widget_theme_get"
> "elm_widget_theme_set"
> all must be treated as methods.
In this case you have a class called "Elm_Widget" that has a property
"theme", am I right? And a method with the same name "theme". That's a
name clash which ideally should be solved by changing the name of either
one:
elm_widget_theme_default()
elm_widget_theme_set()/_get()
or another way:
elm_widget_theme()
elm_widget_theme_specific_set()/_get()
(which would then clash with elm_widget_theme_specific().)
In the Python bindings we can actually hack around this issue, with the
property acting as a method, by making the object returned by getter
callable.
It would certainly make things easier if these name clashes were
forbidden in the APIs completely. We can't change the legacy API but as
I understand Eo and Elm_Widget APIs are both unstable currently and can
still be improved in this regard.
>>>>
>>>> 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.
>>> Have you looked into YAML?
>>> https://en.wikipedia.org/wiki/YAML
>>>
>>> It has similar features to JSON while being more compact.
>> It is the first time I look at it. It is indeed more compact, but I am
>> not sure it is easy to get how to use it for new comers.
>>
>>> If the choice is between C-like syntax and JSON, I'll go with JSON as
>>> it's easier to create a forward compatible parser/lexer for it, and
>>> because of the reasons you mentioned above. But this should not depend
>>> on a single round of voting, we should strive to find a syntax and
>>> structure which serves all our relevant needs and is easy to work with.
>> I think we are not committed yet to either C-like or JSON syntax, this
>> discussion and thread is a good opportunity to raise your voice and
>> see if we can find a better solution.
>>
>>> P.S. I am interested to work on the language bindings aspect of this
>>> after 1.8 Python bindings are released.
>> Cool :-)
> Cool!
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
