Yo,
On 10/28/2013 04:02 AM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 22 Oct 2013 08:43:14 +0200 Raoul Hecky <raoul.he...@gmail.com> said:
>
>> I'm also more for json, it allows other tools to parse the files and
>> you don't need to learn a new syntax...
> except syntax is pretty moot... it's like saying "hey - i can understand
> finnish because they use the same punctuation as english!".
>
> json is merely the punctuation. the rest is custom vocabulary to eolian.
>
> if we use json we will end up with doing things like:
>
> "method_name_here_in_quotes": {
> "return": "unsigned long",
> "params": [
> { "type": "const char *", "var:" "string" }
> { "type": "unsigned int", "var:" "value" }
> ]
> }
>
> vs a much easier to read and write (for someone doing C - our audience):
>
> unsigned long
> method_name_here_in_quotes(const char *string,
> unsigned int value);
>
> one of them looks like something a developer can read, write and maintain. the
> other looks like it is a database dump. in json pretty much everything will
> just become strings that you have to eternally quote all the time because a
> type can have a space (unsigned long, const char *, etc.).
>
> the point of eoilian is to cut down work and boilerplate and make it easy to
> just simply declare in shorthand the obvious classes, inheritance and methods
> that will then GENERATE the C code so you don't have to write mountains of the
> boilerplate.
>
> both "c style" and "json" formats are extensible. arguments that the json is
> instantly understood and the c style is not are bogus - because the work is in
> the vocabulary (which has to be learned in either case), and the c style is
> closer to being directly what we already write just minus some namespacing
> preamble. the json looks alien.
Of course, both are extensible. The problem is the price. When we
generated the .eo files from the Eo classes, we encountered some issues
(read-only properties, comments specific, virtual pure) that I will not
re-explain here. They can be solved in both cases, but in C, it will
seem more like patches in the language (at least, imo).
>
> remember daniels example was just covering properties which much more cloesely
> resemble data structures ala json - try actually define real methods with it.
You will have to give an example because most of the EFL functions look
like that. And if you really want to describe complex functions, like
something that returns a list of objects, you will have to specify the
element type (i.e Eo *) for the bindings and it will no more seem like a
C style (but more like that some C++ template).
> not to mention the c style will indent, format and hilight like c - with
> comments (the description fields) nicely colorized, but to a json syntax
> hilighter its a sea of generic strings all the same color.
Well, for this point, I have the solution :). We can create a simple
application (that will be used as plug-in in some next century IDE) that
will show you the eo file colorized, how the C/C++/JS... code will look
like and so on.
>
> c style will be more compact, easier to read, write, format, hilight and
> maintain. json is a shortcut bit of trendiness that we will suffer from for
> years. the COST of doing the c style is the parser. that i do understand is
> something undesirable to make, but consider the cost of forcing the verbosity
> of
> json in when the point is to nuke the verbosity.
I really don't know how the language will evolve (not just the JSON but
the C one too) and which one is the best for our cause (well, that's why
I began this discussion;-)). And of course, my preference is for JSON
(easy parsing and readability really acceptable, at least imo).
>
>> --
>> Raoul Hecky
>>
>>
>> 2013/10/21 Jose Souza <zehortig...@profusion.mobi>:
>>> json++
>>>
>>>
>>> On Mon, Oct 21, 2013 at 5:38 PM, Davide Andreoli
>>> <d...@gurumeditation.it>wrote:
>>>
>>>> Json +1 also for me, It is more clear that is a descriptive thing and not
>>>> real code.
>>>> It is also more easily parsable by other tools/languages
>>>>
>>>>
>>>> 2013/10/21 Gustavo Sverzut Barbieri <barbi...@gmail.com>
>>>>
>>>>> JSon +1
>>>>>
>>>>> On Mon, Oct 21, 2013 at 3:29 PM, daniel.za...@samsung.com
>>>>> <daniel.za...@samsung.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I would like to discuss about a project that we are beginning just now.
>>>>>> I presented it on EFL dev. day yesterday but I would like to share it
>>>>>> here since it will imply all the EFL developers (yes, you) one day or
>>>>>> another.
>>>>>>
>>>>>> It is called Eolian and was first aimed to facilitate addition of new
>>>> Eo
>>>>>> functions by auto-generating code. Then we noted that we can
>>>>>> automatically generate language bindings too but it is not the goal of
>>>>>> this discussion.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> We thought about two formats:
>>>>>> - a C-like format:
>>>>>> Evas_Object_Image =
>>>>>> {
>>>>>> inherit
>>>>>> {
>>>>>> Evas_Object;
>>>>>> }
>>>>>> properties
>>>>>> {
>>>>>> /* Set the DPI resolution ... */
>>>>>> load_dpi(double dpi /* dpi resolution*/);
>>>>>> /* Apply the source object's clip to the proxy */
>>>>>> source_clip(Eina_Bool source_clip);
>>>>>> /* Set whether the image object's fill property ... */
>>>>>> filled(Eina_Bool filled);
>>>>>> /* Get the kind of looping the image object does. */
>>>>>> ro animated_loop_type(
>>>>>> Evas_Image_Animated_Loop_Hint hint /* hint */
>>>>>> );
>>>>>> /* Get the number times the animation of the object loops. */
>>>>>> ro animated_loop_count(
>>>>>> int loop_count
>>>>>> );
>>>>>> }
>>>>>> methods
>>>>>> {
>>>>>> /* Set the source object… */
>>>>>> source_set(
>>>>>> in Evas_Object* src /* in */,
>>>>>> out Eina_Bool* result /* out */
>>>>>> );
>>>>>> /* Get the current source object ... */
>>>>>> source_get(
>>>>>> out Evas_Object** src /* out */
>>>>>> );
>>>>>> /* Begin preloading an image … */
>>>>>> preload_begin();
>>>>>> /* Mark a sub-region of the given ... */
>>>>>> data_update_add(
>>>>>> in int x /* in */,
>>>>>> in int y /* in */,
>>>>>> in int w /* in */,
>>>>>> in int h /* in */
>>>>>> );
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> For C developers that we are, it has the advantage to be easier to our
>>>>>> eyes. It fits most of the needs but still lacks for specific points:
>>>>>> - if we have a property whose comment is different for set and get, how
>>>>>> can we describe it? By inserting "tokens" inside the comments
>>>>>> themselves, meaning parsing of the comments is needed.
>>>>>> - if we want to define a function as virtual pure, do we use the so
>>>>>> loved C++ notation "= 0"?
>>>>>> - properties that are read-only or write-only (only get or set): do we
>>>>>> add some ro/wo parameter, as in the example?
>>>>>> ...
>>>>>> People complained that it seems too much like C++.
>>>>>>
>>>>>> - JSON format:
>>>>>> {
>>>>>> "class_name" : "Evas_Object_Image",
>>>>>> "inherits" : [ "Evas_Object" ],
>>>>>> "properties" : [
>>>>>> {
>>>>>> "name" : "load_dpi",
>>>>>> "description" : "DPI resolution ...",
>>>>>> "parameter" : [
>>>>>> {
>>>>>> "name" : "dpi",
>>>>>> "type" : "double",
>>>>>> "description" : "dpi resolution"
>>>>>> }
>>>>>> }
>>>>>> ... (don't have the force to write all ;-)
>>>>>> }
>>>>>> The format is less intuitive to C developers and there is more to write
>>>>>> but it is extensible and so easily solves the issues described in the
>>>>>> C-style.
>>>>>>
>>>>>> So, until yesterday (the day I presented), I really thought we would go
>>>>>> on the C (ok, C++) style but now that I saw some faces when I showed
>>>> the
>>>>>> C format and since I want to come back home safe, I prefer asking here.
>>>>>>
>>>>>> Thank you for your help
>>>>>> JackDanielZ, alias Daniel Zomething
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------------------------------------------------------
>>>>>> October Webinars: Code for Performance
>>>>>> Free Intel webinars can help you accelerate application performance.
>>>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most
>>>>> from
>>>>>> the latest Intel processors and coprocessors. See abstracts and
>>>> register
>>>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> enlightenment-devel mailing list
>>>>>> enlightenment-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>>
>>>>>
>>>>> --
>>>>> Gustavo Sverzut Barbieri
>>>>> --------------------------------------
>>>>> Mobile: +55 (19) 9225-2202
>>>>> Contact: http://www.gustavobarbieri.com.br/contact
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------------
>>>>> October Webinars: Code for Performance
>>>>> Free Intel webinars can help you accelerate application performance.
>>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>>>> from
>>>>> the latest Intel processors and coprocessors. See abstracts and register
>>>>>
>>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> enlightenment-devel mailing list
>>>>> enlightenment-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>>
>>>> ------------------------------------------------------------------------------
>>>> October Webinars: Code for Performance
>>>> Free Intel webinars can help you accelerate application performance.
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>>> from
>>>> the latest Intel processors and coprocessors. See abstracts and register >
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> enlightenment-devel mailing list
>>>> enlightenment-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from the latest Intel processors and coprocessors. See abstracts and
>>> register >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>>> _______________________________________________ enlightenment-devel mailing
>>> list enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
