On Fri, Mar 31, 2017 at 07:59:01PM +0900, Carsten Haitzler wrote: > On Fri, 31 Mar 2017 11:55:34 +0200 marcel-hollerb...@t-online.de said: > > > On Fri, Mar 31, 2017 at 06:19:53PM +0900, Carsten Haitzler wrote: > > > On Fri, 31 Mar 2017 16:00:52 +0900 Conrad Um <con...@gmail.com> said: > > > > > > > This is similar to bu5hm4n's idea, but a little different. (Not pass by > > > > value, but reference) > > > > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg82744.html > > > > > > > > While studying oop, I found that properties are usually expressed as > > > > struct or object instead of multiple arguments. > > > > > > > > For example, "size" property usually accepts Size struct. > > > > public struct Size { > > > > int width; > > > > int height; > > > > } > > > > obj.size = new Size(100, 100); // This means "obj.setSize(new Size > > > > (100, 100));" > > > > > > > > In languages supporting property accessor expression like C# or Vala, > > > > multiple arguments cannot be expressed with that syntax. I think it is > > > > better to exchange a set of data in the type of object (or struct, it > > > > can > > > > be considered as simplified object). > > > > > > > > Former example can be translated into the next. > > > > Size size = { 100, 100 }; > > > > size_set(obj, &size); > > > > > > > > I know "size_set(obj, 100, 100)" is more simpler, but handling related > > > > variables with one set is more reasonable in point of oop. (Or we can > > > > add > > > > c wrapper function like calling eo API by legacy API for more simple > > > > function signature) > > > > > > > > What do you think of this? > > > > > > i've thought about this before, and realistically using such structs for > > > size, geometry, color etc. just is more of a pain than a gain. it > > > theoretically looks nice but it just becomes far more of a pain in real > > > life to use. in general code gets longer and more verbose, not nicer. > > > > I dont think so at all. Just take it as a example, what looks nicer: > > Eina_Rectangle root, button; > > > > [... here some geometry gets from those two] > > > > Or > > > > int root_x, root_y, root_w, root_h, button_x, button_y, button_w, > > button_h; > > > > [ ... here the rest] > > > > What is more verbose? > > > > > > Just take a look at the elm_scroller code how much pain it is there with > > all the coords definitions. (elm_scroller.c:85, the _key_action_move > > function) > > > > Also, just having the var name once and not 4 times maybe invites to > > find better var names than c & v :P > > getting geometry or size or color is rarer than setting. some numbers for > elementary's code: > > color_get: 9 > color_set: 93 > > geometry_get + position_get + size_get: 380 + 5 + 4 (389) > evas_object_move + resize + size_set + position_set: 133 + 146 + 97 + 90 (466) > > in enlightenment: > > color_get: 14 > color_set: 128 > > geometry_get + position_get + size_get: 325 > evas_object_move + resize + size_set + position_set: 261 + 321 (582) > > > so COMMON code to set goes from: > > blah_set(obj, 10, 20, 30, 40); > > to: > > Color blah = {10, 20, 30, 40}; > blah_set(obj, blah); //or &blah > > > so it becomes FAR more verbose. a get goes from: > > int r, g, b, a; > blah_get(obj, &r, &g, &b, &a); > > to: > > Color col; > blah_get(obj, &col); > > or maybe: > > Color col = blah_get(obj); > > > if you want to do struct returns (complex type returns). at BEST it is even > and > the gain on a get matches the LOSS on the set (you can typecast inline on the > set too and it just gets very long - so the same). > > BUT since sets are far more common than gets... you would overall lose. also > as > a barrier of entry to learning having to write code like: > > Color blah = {10, 20, 30, 40}; > blah_set(obj, blah); > > vs > > blah_set(obj, 10, 20, 30, 40); > > really just make learning an api far more complex as really the first examples > people will learn are all sets not gets. > > historically gfx api's far more commonly break out colors, coordinates etc. as > params than group them into "complex types". i've seen a lot of gfx api's in > my > life. from opengl through to cairo through to lots of very old ones (in basic > and other languages) ...
Well the question here is since you are looking in e and efl, who often is geometery just setted to specified values? Isnt it most of the time setted to some relative value depending on a previous get? So the workflow is more get + modification on the container + set again. Which would be less code since most container functions in eina are offering usefull utility function, and if they do not, then its time to add them, since i would consider that common code. And still, we can generate 2 function types for containered function calls, one with the container one with the direct values, foo_set(rect) foo_set_D(x,y,w,h) for example, so even for the usecase of setting hardcoded values to a geometry you could have the direct way. > > > Greetings > > bu5hm4n > > > > > > > > > Regards, > > > > Jeeyong Um (conr2d) > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
