while I get most arguments, my preference is always to stick with
higher lever, more meaningful types... as explained in examples in
this thread, most confusing usages is when you have 2 sets of data,
like "cur, prev", then you come from 4 to 8 parameters (ie: color) and
errors are easier to happen.
benefits of having clear high level types is option to offer some
helpers for them, like rectangle intersection, getting the top-left,
top-right, bottom-left, bottom-right, center... points of a rectangle
instead of cumbersome manual math most people that are not used to gfx
don't get at first (cx = x + w / 2).
as we're taking a new API for Eo, we could take the opportunity to
improve that before removing BETA flag.
In C we could do single-line as:
Eina_Rectangle r = efl_bla_geometry_get(o);
efl_bla_geometry_set(o, r);
efl_bla_geometry_set(o, eina_rectangle_intersection(r, boundary));
efl_bla_geometry_set(o, eina_rectangle(0, 0, 10, 20));
efl_bla_geometry_set(o, (Eina_Rectangle){.w = 10, .h = 20});
On Fri, Mar 31, 2017 at 10:14 AM, <marcel-hollerb...@t-online.de> wrote:
> 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
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
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
