On 04/14/2013 10:27 AM, Carsten Haitzler (The Rasterman) wrote: > On Sun, 14 Apr 2013 10:06:47 +0300 "daniel.za...@samsung.com" > <daniel.za...@samsung.com> said: > >> Hi Raster, >> >> If I understand correctly, you would like to add some layer above Eo >> that would simplify writing code. I don't think people suffered enough >> to "hide" Eo ;-) >> As you said, a lot of details have to be checked, like for example how >> do you call these functions? with the previous writing way or with a >> shorten one? >> Same thing with eo_data_get and eo_do_super. > you call like now: eo_do(obj, methoda(x,y,z), methodb()); > etc. we are just talking of how to cut down the boilerplate and reduce errors, > maing it easier. If we take your example, what is methoda? font_source_set or eo_font_font_source_set? With the first one, we must be sure there is not the same function name in another class (for the moment, we have this kind of issue). With the second one, the developer has to guess the function name. > >> If we really go on this way, I would suggest to change the manner get >> functions return the values. Maybe something like Python. But here, same >> as before, have to check all the corners. >> >> Imo, we don't need to re-invent a new language that will take time to >> adapt to the existing code and may not be approved by all the world (as >> with Eo). I think a tool is preferable so I would go to something like >> Cedric proposed. And DO NOT THINK I agree with Cedric because we are >> both French (and you not) !!! > not thinking new lang. just thinking easier way to declare all the eo > boilerplate and maintain it. its really just a better cpp before cpp. i don't > see why not to be able to just write my c code method content right there and > then. otherwise this generator has to not just generate code by EDIT existing > code that you will have edited after intial generation as opposed to just > generate the surrounding boilerplate c ANd insert the code you just wrote as > part of it. I understand your point. But the real question is which issue we want to solve. If we just want to add/remove Eo functions, a simple tool is easy to write, sufficient and could be easily integrated into a future EFL IDE. Updating the code is the hardest part but a simple C parser can make the work easy (imo). If we want to adapt the syntax to the developer mindset, it is another story that will take more time with more virulent discussions (hehe, as usual in open-source). But it could be a better long-term solution. I really don't know.
Maybe we need both tools. The simple tool for now, with possibility to extend meta-data files to accept code in the future. And in parallel, thinking and designing a new way to develop on EFL. > >> JackDanielZ, your favorite larbin >> >> On 04/11/2013 02:09 PM, Carsten Haitzler (The Rasterman) wrote: >>> On Thu, 11 Apr 2013 14:06:04 +0900 Cedric BAIL <cedric.b...@free.fr> said: >>> >>>> Hello everyone, >>>> >>>> One of the annoying things with Eo is that we now need to update a few >>>> more place than before when we add a new function. We have to do : >>>> - Add enum at the proper place in header >>>> - Add macro for the function call in header >>>> - Add function with proper argument in the C file >>>> - Add declaration at the right place in the object table in the C file >>>> - Add description at the right place in the description table in the C file >>>> If necessary, we also have to do >>>> - Add legacy prototype function in header >>>> - Add legacy wrapper function in c file >>>> >>>> Of course when you create a new object you have even more boilerplate >>>> to write. In fact, most of it can be inferred if we did have a >>>> properly detailed prototype. So I would like to propose a tool, eo-gen >>>> that would take a "json" like format (see a possible example there: >>>> https://phab.enlightenment.org/P17 ). From this description file, it >>>> will generate or update the .c and .h file. This json file would be >>>> included into the distributed header of our library, so it could be >>>> used by other tools. >>>> >>>> To properly update the .c/.h files, it will search for a know pattern >>>> in the comment and use that to infer what is going on. Once using >>>> eo-gen, it will not be possible to remove those comment without >>>> breaking the capability to update the source. >>>> >>>> I know that some people have also been thinking about this problem, so >>>> let's try to find a common solution there. >>> frankly i would prefer a syntax that works with the programmers >>> mindset/mode of working better: >>> >>> https://phab.enlightenment.org/P18 >>> >>> and this leads onto the next logical step: >>> >>> https://phab.enlightenment.org/P19 >>> >>> ie you can even place the code for methods right into the template and they >>> get output along with the boilerplate. (in this we make objd always be the >>> object private data etc. - sure some things not handled/explained - more a >>> position on syntax style and where it leads). >>> >>>> -- >>>> Cedric BAIL >>>> >>>> ------------------------------------------------------------------------------ >>>> Precog is a next-generation analytics platform capable of advanced >>>> analytics on semi-structured data. The platform includes APIs for building >>>> apps and a phenomenal toolset for data science. Developers can use >>>> our toolset for easy data analysis & visualization. Get a free account! >>>> http://www2.precog.com/precogplatform/slashdotnewsletter >>>> _______________________________________________ >>>> enlightenment-devel mailing list >>>> enlightenment-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>>> > ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
