On 03/04/12 01:53, Gustavo Sverzut Barbieri wrote: > 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.
As I said before, I haven't tested eina_value, I really don't know about this one, and that's my problem with it. I don't feel it was tested enough (API + code). Perhaps it's ready for prime-time, but without people actually playing with it, and real code in EFL actually benefiting from it, it's just too hard to know. > > - 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. As I said, it's not just about test coverage, it's about API's validity. I just don't think we want to "get stuck" with this API for ages without testing it before. What's the rush? really? We don't depend on it anywhere inside of EFL, so there's no real reason to rush it into our release. You can just create a profusion lib with the same symbol names and headers and just migrate to eina when it's ready and in the next release (if we find it fit then). > > - 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. My example is not synthetic, I stumbled across it in a *real life* example I was implementing. And it *DOES* break API/ABI. While the functions may remain the same (uncertain) their behaviour is changed, and as you said yourself, actual usage ("force an unneeded dep") will change. Also, this is the tip of the iceberg, we don't know what else lies beneath. > > - python, which uses the same object implementation for everything, > used a similar naive implementation for almost 10 years before > changing it. So are you suggesting we should lock ourself to one flawed design just because others have done the same in the past? > > - 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. Which changes the behaviour!!! > > - 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. But people may have other uses (as shown in my example). > > - aside from interfaces exceptional corner cases, I did not see any > other relevant comment to Model; Because it was not tested enough. But as I said, there are some other things that are wrong in the API. I'm 100% sure I've told you about them in IRC, but maybe also in mail. It's still rough. > > - 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). It is rushing, I say there are flaws, you admit there are some flaws, but still we are trying to get it in. Time it has been in svn has little relevance to this, it's the amount of review it got that matters. > > - 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. EFL is released in sync, we can implement it in eina and add it to all of the above while in svn, like we do with all other features. That's hardly an excuse... > > - 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. Knowing your code is not perfect is one thing, but knowing the API is flawed (or potentially flawed) is another. FIXME/TODO are fine, but not when they refer to the API. > > 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. Like I mentioned many times before. I don't feel like enumerating the flaws again, nor do I remember all of them. Lets wait for other people to review as well and let them comment. > > 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. I know it's not a general object. Again, I'm not talking about whether it's needed or not (that's a different discussion that should be raised), but I'm talking about whether it should get into next release, and I think that it should not. -- Tom. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
