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 <[email protected]> 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,
but without deleter, as there is no color property in object actually.
So we will not provide deleter in eo-mata in this case.
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?
>>> 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.
>>>
>>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
