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.
> 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.
> 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.
>> 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?
>
>>
>>
>> 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 :-)
--
Cedric BAIL
------------------------------------------------------------------------------
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
