On Thu, Sep 3, 2009 at 9:45 PM, Carsten Haitzler<[email protected]> wrote: > On Wed, 29 Jul 2009 19:46:20 -0300 Gustavo Sverzut Barbieri > <[email protected]> said: > > overall i like the idea. it's a more structured way to have arbitrary smart > callback signal names. it's runtime discoverable. while we're at it...
I have it written already, just needs testing. Sachiel and I were starting to test it, but then we ran into other stuff and then snapshot came and I rather focus on eina than it. As my patch also covers inheritance with Evas_Smart_Class->parent I thought some things would work but I overlooked and I'll have to remove some code and add some glib-like macros (like G_DEFINE_TYPE()) to help declare smart classes and call parent class stuff. > it means > the strings are in an array/table. they should be stringshared. imho this > means > that the class either should declare them with eina_stringshare - or a > function > that takes and array of strings will stringshare each into an internal array. > then we can use > > if (x == y) > > instead of > > if (!strcmp(x, y)) > > (in fact i just changed in svn evas_object_smart_callback_call() to create a > temporary stringshare of the event string to turn the compare into a ==) I saw your commit and realized that quickly. I have another suggestion/approach to speed it a bit more. Since we can know beforehand the class/instance signals, on the first connection we can create an array of that size. This array would contain buckets with [name, list-of-connections], since I keep names sorted already, we can do binary search on it. It's no pointer comparison, but on the other hand we don't have to walk a list of all signals, we cut straight to the chase and dispatch all signals once we find their buckets. Of course we need 2 special cases: - no signal connections has no array, so just ignore. fast and saves memory. - signals connections of unregistered name: warn but add them to another bucket that will be looked once it's not found in named buckets. This one would behave like current approach and can be optimized with stringshare, but I'd say it will be a not so common case that do not worth. In my implementation all strings are references to those given in Evas_Smart_Class->callbacks array, so I use pointer comparison if users want to make it fast by having global pointers that are shared (let's say, by an EAPI const char *variable) > as for format string of the event_info. i see no reason why not. sometimes > it's > opaque though. ie an object handle. need a way to be able to specify that too. yes, they're just hints. However we could have a high level type "o" that is an Evas_Object. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
