On Thu, Jul 30, 2009 at 1:58 PM, Gustavo Sverzut Barbieri<[email protected]> wrote: > On Thu, Jul 30, 2009 at 6:28 AM, Cedric BAIL<[email protected]> wrote: >> Hi, >> >> On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut >> Barbieri<[email protected]> wrote: >>> = Solution = >>> I would like to avoid breaking current code, so changing things >>> drastically is a no go. I could also propose a new system with signal >>> inheritance and index access to speed up dispatching and all, but I >>> guess the best is to build on top of existing stuff as it's "fine" for >>> our use cases. >>> >>> The proposal is to add an array/list of signals-types to >>> Evas_Smart_Class. This array would be defined when class is created >>> and should not be changed afterwards. Types would be DBus-like type >>> strings >>> (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >>> for example "iis" is accessed as a struct with two leading integers32 >>> followed by a string. >> >> Hum, why not EET_DATA for that ? We have EET_DATA_DESCRIPTOR for the >> description. We should be able to generate from/to object script too. >> >>> USERS: We could write a script to extract such information from C >>> files and generate documentation. >> >> I was thinking about this using EET_DATA_DESCRIPTOR, we should be able >> to generate doc. Or we could do the other way around with a simplified >> syntax, we could generate C file that provide EET_DATA_DESCRIPTOR >> alongside with documentation (based on the same idea as bison, flex or >> gperf). >> >> This way it would be easier to use EET_DATA for more thing like >> network traffic (it's way faster to process eet_data than xml), IPC. >> >> What do you think about this addition to your proposal ? >> >> Note, that I like the idea you are proposing for some kind of object >> inheritance with evas_smart, this would bring some usefull capability >> to the EFL. And I would just use the ->parent mecanism for almost >> every thing including signal inheritence. > > > Regarding EET_DATA, I did think about it as well, but I like the > string types more for some reasons: > - simpler to use inside evas, it's just a string. and unless we > want to do debugging checks, we don't need to use it in fast paths so > performance is not an issue here > - simpler to use by scripts, just iterate a string and output list items. > - simpler to use by bindings, EET_DATA is useless for Python, for > example. I would like to use write some "common dispatchers" like > _evas_smart_callback_dispatch_iis() and do the generic just if > required, later. To do so with strings I just need to add a hash > table.
Hum, I would have say an array, as we don't have key name in front of the value. Beside that, I know that currently, their is no easy way to generate an Eet_Node tree from an Eet_Data structure. This limite the automatic transformation from Eet_Data to Script object. But as I already did the other way around from Eet_Node to Eet_Data (meaning it is possible to generate Eet_Data from a Python object quite easily now), I plan to do this shortly as I need it (And it will clean Eet_Data internal in the mean time). So at some point, it will not be that much useless to have an Eet_Data/Python Object converter. > All in all they're almost the same thing and the result would be the > same, but i think it's easier to do so using strings... I can see this > getting cumbersome to create eet_data_descriptors and all for every > single signal one may emit... Yep, definitively. > My proposal lacks a "name" entry for each value, which EET_DATA > provides... do you think it is important to be inside code? On one > hand it would be good to have this information, but on the other it > would make declaration more complex and parsing harder, if we keep > these 2 separate (to make parsing simpler) we can easily get out of > sync. Maybe a format like TYPE:NAME,TYPE:NAME.... like > "i:old_value,i:new_value" would do, then in Evas_Smart we can split > and keep just the types... That was my reason behind eet, having the possibility to name each chunk easily and with some meaning (it would ease the creation of binding, as we will have real object with propertie name). So yes, I like name, but I don't like the idea of a new "protocol" to parse. So I will disagree on putting a complex scheme like that. Or we ease EET_DATA use, with some tool that generate EET_DATA_DESCRIPTOR, or we go to the easy and small path of your first proposal. I prefer EET_DATA as it's really easy to use in C, and will be for script to. We just need an way to represent it in our documentation. The drawback is that it would make Eet a strong dependency for Evas, not a big deal in my opinion. > Evas_Smart could contain other pre-processed data, such as sorted > version of all known callback names inherited. This would enable > instances to speed up signal dispatching. Instead of a single list > with (callback_name, func, data) we would have an array/hash of > (func,data) lists and could do binary search on it for quick finding > the correct list of functions for that callback name. A small hash table will do the trick and be fast enough, without consuming too much memory (as it is shared by all object from the same type if I understood correctly). -- Cedric BAIL ------------------------------------------------------------------------------ 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
