24.11.2013 13:01, daniel.za...@samsung.com kirjoitti:
> On 11/24/2013 11:34 AM, Yakov Goldberg wrote:
>> 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.
> And we could assume that we have to generate set and get if no set/get
> section is specified. comment would be under the name directly. Does it
> seem ok?
I feel the sections should be there as needed; if there is this kind of
empty default behavior it would confuse the poor unassuming reader.
One comment field for the entire property seems ideal to me as well.
>>>> 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.
> I don't think setting properties as methods is wise. It will create
> inconsistency when for example we will access in live the Eolian database.
> We need a way to resolve the conflicts and conserve legacy API as is.
> If we take theme as example, we can change the method name to
> theme_apply and indicate via the flag legacy_override that the legacy
> API name is elm_widget_theme. Only legacy will be different from the
> other languages (Eo, Python, C++...). Eo will be changed to
> ...SUB_ID_THEME_APPLY.
> In this way, we respect the legacy style and fail a compilation if a
> same name is used in properties and methods sections.
>>>>> 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
>
------------------------------------------------------------------------------
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
