[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-announce
Subject:    Re: [Enlightenment-announce] [E-devel] New EFL release cycle 1.0/1.2/1.6 ALPHA
From:       Carsten Haitzler (The Rasterman) <raster () rasterman ! com>
Date:       2012-04-15 5:15:15
Message-ID: 20120415141515.72fb9522.raster () rasterman ! com
[Download RAW message or body]

On Mon, 2 Apr 2012 19:53:28 -0300 Gustavo Sverzut Barbieri
<barbieri@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 :))

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.hacohen@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: barbieri@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com


------------------------------------------------------------------------------
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-announce mailing list
Enlightenment-announce@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-announce
[prev in list] [next in list] [prev in thread] [next in thread]