On Thu, 19 Jun 2014 18:02:02 -0300 Felipe Magno de Almeida
<felipe.m.alme...@gmail.com> said:

> Hello Raster,
> 
> On Thu, Jun 19, 2014 at 12:20 PM, Carlos Carvalho
> <ccarva...@expertisesolutions.com.br> wrote:
> > Hi raster :)
> >
> > please see below.
> >
> > On Thu, Jun 19, 2014 at 4:09 AM, Carsten Haitzler <ras...@rasterman.com>
> > wrote:
> 
> 
> > > can i recommend we have a path property you can
> > > set AND get? so you can create an empty eio model and then point it to a
> > > path?
> > > cleaner. a custom constructor is fine but we eventually want to get rid of
> > > them
> > > or as many as we can.
> >
> > Making a generic constructor I don't know if would make much sense because
> > of different implementations for emodel. But we're are very open to change
> > this if you think it is a good idea os have something in mind I don't though
> > about.
> 
> This was dicussed some times here and I felt a default-constructor is
> going to make implementations of the model much harder and more
> confusing. Why? Because the backend needs information to create a new
> child and each backend needs a different information. So, the backend
> has to choose between two options: use default, arbitrary,
> information; or delay backend instantiation until it has enough
> information, returning a "zombie" child.

sure. it needs the info, but then it makes the interface less clean/easy. :)
the object can exist in memory but the on-disk version will not be created
until enough information is there to do it. so to me its easy - every piece of
info you need like type (dir, link, hardlink, file, device inode) and then some
extra info per type (link and hardlink need destination, device inode need
major/minor number) and they ALL need a filename. every time you set one of
these you call "eval" internally int he impl. the eval then creates the file/dir
if enough info is there now, if not - it just returns. eval is just passed all
theinfo it needs like prev and current name, the file node obj of course. you
only call on changes internally and this eval can handle all the transitions,
renames, etc. :)

> Both options are bad. The first needs to guess arbitrary, valid,
> information and might very well corrupt the concrete data with random
> information (e.g., finantial database with default-constructed items).
> The second doesn't commit to disk until enough information is given,
> which means that data might be inadvertently lost and requires a
> branch for each function  called (do I get this property from disk or
> from a temporary hash?), which doubles the implementation's size (for
> smaller implementations).
> 
> And, it is not really generic anyway, you still need to know which
> information is necessary for each kind of child. But, we could have a
> efl_child_addable interface (not loving the name, but you get the
> idea) for models that decide to implement a child_add function for use
> with generic views.
> 
> 
> > --
> > Expertise Solutions
> 
> Kind regards,
> -- 
> Felipe Magno de Almeida
> 
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to