On Sat, 20 Jun 2009 00:03:14 -0300 Gustavo Sverzut Barbieri
<[email protected]> said:
> > to be realistic - this will never make a difference. you many gadgets do you
> > expect to have in a list? 100? 1000? more? you know that if 1 module
> > provides 1 gadget... you'll run out of fd's long before you have enough
> > items for this to matter. this is micro-optimisation with no real effect. :
> > ( every list item created will probably do dozens and dozens of strcmp's.
> > this won't make a dent at all. even if they were all removed you'd still
> > barely notice. :)
>
> But why do a not so good solution when the other solution is actually
> simpler code-wise? You'd be changing handling of pointers (!NULL) and
> then a comparison by just comparing two values.
because it does something a little evil. it assumes ALL strings are stringshare
strings. this means if the module has:
if (!strcmp(site, "shelf"))... it won't be able to use the built-into-module.so
file "shelf" string. you need to do:
mysite = eina_stringshare_add("shelf");
if (site != mysite) {
...
eina_stringshare_del(mysite);
}
...
eina_stringshare_del(mysite);
yes. you need to add it then del it when you exit or dont need it any more etx.
so you actually made the code more complicated AND you now assume that the
string is stringshare. this is relatively evil to do between abi's. within a
single app/lib it's evil, but ok, but modules and e are like 2 sides of a
library api. these kind of assumptions pretty much exposing internal
functionality, is pretty evil. and for more complicated code, exposing
internals where not really needed, all for the sake of a speed gain i challenge
you to actually measure ever in real life :) just need to be careful where to
focus efforts. don't focus them where you make the least or no gains. :)
> Actually, after discussing this Sergey just wisely remembered that we
> should use simple ENUM/integers and that gets even more simpler. Given
> the number of things this could grow, I would even say that integers
> should be powers of 2 and use a mask of accepted types, then no need
> to do functions and all, just set your mask and be happy.
>
>
> >> Last but not least, since we have common stuff here, provide the
> >> following functions by default:
> >> - PREFIX_only_shelf_is_site()
> >> - PREFIX_only_desktop_is_site()
> >> - PREFIX_only_efm_toolbar_is_site()
> >> - PREFIX_not_efm_toolbar_is_site()
> >>
> >> they should be used by modules to avoid duplication, and you can have
> >> them to use the globals with the stringshared version of names you
> >> created before (at init time).
> >
> > what are these funcs. it's not clearly explained.
>
> they would be common functions most modules would set instead of
> creating their own replicas, like defining this in every module:
>
> BLA_is_site(const char *query)
> {
> return (!query || strcmp(query, "desktop") == 0);
> }
>
> one would set: is_site = PREFIX_only_desktop_is_site. (PREFIX = some
> prefix we choose for this, like e_gadcon_client).
but what is PREFIX? gadcon_helper_only_desktop_is_site ? or the module name?
what? :)
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: [email protected]
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
