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) ...
> 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
