On Sun, 15 Apr 2012 14:15:15 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Mon, 2 Apr 2012 19:53:28 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > > here's my take - and i'm fast-forwarding including more comments from tom > later. > > FIRST: > > 1. just because it isn't used elsewhere in efl or e atm should NOT be a reason > for exclusion. if it has a good use case somewhere that's more than a one-off, > it is a candidate to go in a release. > 2. we have lots of stuff that is barely tested, so testing is very good and > needed, but it has never been a necessity. we get to test and fix eventually. > 3. what matters is the IDEA is sane and the API is sane. it won't conflict > with other parts of efl (nor or in the forseeable future). it can be expanded > in future. if we have missing things or bugs they can be fixed without > creating havoc with existing apps using the api. the usual thing here. > > NOW: > > eina model/value. the reason really tom has is that here are 2 new fairly > hefty api's with really no "use cases" floating about to see other than > example files or tests. the rest of the reasoning is really just justifying > this base. so lets focus on this. > > i haven't looked beyond a cursory glance thus i have no deep meaningful > insights, but let me make an attempt. :) > > 1. eina value > > * it is heftily documented, so i can't complain. > * it's pretty darned big. > * it seems very heavyweight in a c world for holding and dealing with > "values". it smells like the kind of logic u find in bash or perl or other > scripting langs where variables are dynamically typed - they may be a string, > a number, a float etc. and they keep shifting type based on how you use them > = eg a = b + c ... will store the numeric result of b + c... as long as both > b and c are sanely interpretable numbers (even if both strings- of both are > strings of numbers etc.). so that's what this looks like to me. find - if u > are writing a scripting engine this can be useful. > * could you please go into what eina_value is useful for? what did you > develop it for? what was the driving reason? > * other than the above questions it seems pretty sane and reasonable. i don't > see any problem shipping with it as-is (API-wise). i will trust that it has > been actually used and tested and deployed - we just can't/don't see it (thus > why i'm asking you to tell us about it :)) not to weigh in on either side because I don't really care, but eina_value has been deployed in esql since january. nobody that I know of uses esql, but it does work. sometimes. > > 2. eina model > > * this is where i have issues. it is yet another object model or well a very > heavily property-based object model somewhat like gobject, the eobj stuff tom > is working on and so on. > * i think this should be held back from release while we have our object > system wars and work out where everyone fits in. eobj stuff has been now up > for comment/review, but eina_model never got a chance for that before it went > into svn. there is just way too much overlap here that needs to be sorted out. > > simple version: > > eobj does callbacks, referencing, parent/child relationships, generic cata > attache (could be seen as properties but is much simpler) and methods and is > varargs centric to cut down overhead. > > eina model does callbacks, referencing, parent/child relationships and > properties, and is single-call centric keeping call overhead higher. > > there is overlap. properties in eobj are done by methods and private data. > > > Hi all, > > > > I'm bit busy at the moment and can't discuss much details, but a > > summary is that I'd really like it to be available as for now. > > > > To clarify few things: > > > > - Eina_Value: it's gold, really. No idea why it was mixed into Model > > discussion. Value purpose is not dependent on Model, although model > > does use it to exchange properties in a safe way. When designing it > > I've researched how glib and qt does that, we could do more with > > optimized handling for arrays. > > > > - Eina_Model: although test coverage is not 100%, it does come with > > much more test than the average code in SVN. ProFUSION is using it for > > customers code without issue, mostly to abstract data access to DB. > > All in all I'm satisfied with the API for MODEL (DATA) usage. > > > > - during Eina_Model development, I create the Interface concept, with > > multiple interfaces per type, and interfaces could extend multiple > > interfaces. But the implementation (internals) assumed for MODEL > > (data) the common case is not to have multiple INDEPENDENT interfaces > > to implement the same, thus I implemented the interface lookups in a > > naive way. THIS is marked in code for future improvements. > > http://trac.enlightenment.org/e/browser/trunk/eina/src/lib/eina_model.c#L524 > > Again, this is an internal issue and can be fixed without changing > > API or ABI. The only synthetic example that exposes this behavior is > > hard. This is example eina_model_04 in SVN, and the "fix" was to force > > an unneeded dependency between interfaces. > > > > - python, which uses the same object implementation for everything, > > used a similar naive implementation for almost 10 years before > > changing it. > > > > - the fix for the above problem is suggested in the TODO, it's about > > changing the algorithm that sorts the dependencies to consider initial > > ordering as well when pulling the roots of topological sort. > > > > - interfaces for models/data is more to help people to override a > > single part without having to do much work. For example the sole usage > > of it now is to independently handle properties and children. > > > > - aside from interfaces exceptional corner cases, I did not see any > > other relevant comment to Model; > > > > - I don't consider the code to be rushed in, as it's in SVN for more > > than 2 months. It went through reviews, documentation, examples and is > > being used in our projects without issues (the found issues were fixed > > in SVN). > > > > - Removing it because it's not in use is chicken-egg. It will not be > > used if it does not exist. As I said I'm bit busy to code right now, > > but I would use Eina_Model to implement, at least (no particular > > order): > > * SQL loader in esql; > > * Eet loader and saver; > > * Eio browser; > > * Enjoy, allowing plugins to provide backend-independent data (SQL > > as now, but also FS or network/last.fm). > > * Elementary to provide views (genlist/grid variants); > > * Python: to let Python objects be used by C code > > implementing/using Eina_Model. > > > > - I'm bit sad to see that knowing your code is not perfect and > > flagging it with TODO to help others is seen as a bad thing. I always > > marked like that, while others just omit those. I don't see why it > > would make it a blocker for inclusion. > > > > Again, this code is intended to map data in a common protocol so we > > reduce code duplication everywhere. It is based on properties and > > children. It does events signaling to notify of changes. It does > > reference counting as multiple views may hold the data. > > And for these cases I really fail to see how it's broken, badly > > designed or with flaws. > > > > What does seems to happen is a confusion with general objects. This is > > not general object. Don't expect Evas_Object to be converted to > > Eina_Model because it has nothing to do. What you should expect is > > every data provider to talk this API and suddenly you could show a > > list of something in Elementary without effort. > > > > []s > > -- Gustavo > > > > > > On Mon, Apr 2, 2012 at 4:03 AM, Tom Hacohen <tom.haco...@samsung.com> wrote: > > > > > > On 02/04/12 05:39, Carsten Haitzler (The Rasterman) wrote: > > > > i was hoping/expecting gustavo to appear in this thread and make his > > > > case. > > > > > > > > > > He's probably unavailable atm. Anyhow, the most important point I raised > > > is the last one. Given that *nothing* in the efl uses it, why are we > > > trying to rush it in? > > > > > > > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -------------------------------------- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
