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

List:       enlightenment-devel
Subject:    Re: [E-devel] [EGIT] [core/efl] master 03/03: config: Simplify EO API
From:       Carsten Haitzler <raster () rasterman ! com>
Date:       2017-10-20 23:33:07
Message-ID: 20171021083307.16f697fc86de5c3336338fa9 () rasterman ! com
[Download RAW message or body]

On Fri, 20 Oct 2017 15:18:45 +0900 Jean-Philippe André <jpeg@videolan.org> said:

> 2017-10-20 8:15 GMT+09:00 Carsten Haitzler <raster@rasterman.com>:
> 
> > On Thu, 19 Oct 2017 14:28:27 -0200 Gustavo Sverzut Barbieri
> > <barbieri@gmail.com> said:
> >
> > > > +         get {
> > > > +            keys {
> > > > +               name: string; [[Configuration option name.]]
> > >
> > > shall we document and handle this as a path, so nested Eets can be
> > > used, such as in E (wm).
> >
> 
> It could be. Why not.
> Then use '.' or '/' for path separator? :)
> 
> I am in fact not very happy about the value type returned, as it's @owned
> (terrible in C... it WILL leak).
> But returning const(any_value) is hard (lifetime of the value? lifetime of
> the strings stored?).

Could we add a "release" method that at least for C will free/delete the data
held in the key? then it can return a non-owned data which will be fine for
non-c lang's as they will use reference counting or gc to handle the values
returned and in c it allows you to tell it to free the data it's holding in
memory for that key if you no longer need it. maybe be able to release parent
key values... use a path-like definition /a/b/c and if you release /a it
releases everything in children too?

> I'm not so sure this config API is "good enough". It is indeed very very
> > simple (string key to single value pair). But history tells me that this is
> > very limiting. I've been here before (edb) and i hit the limits of this
> > pretty
> > fast. I needed SETS of things (a list of strings. a list of keybindings, a
> > list
> > of whatever) very quickly. I think that this should be an API which allows
> > nesting and "sets" (ordered lists/array of items with the ability to
> > append,
> > prepend, insert and remove) and probably also "hashmaps" as well (key ->
> > item
> > lookup). yes. it's more complex, but at least it won't hit a wall really
> > really
> > fast and then we need to extend this api so it begins to look a bit ugly
> > after
> > extending.
> >
> 
> Meh. Sets, lists, structs, etc... can all be stored in the Eina_Value.
> 
> also i'm not sure if it should also allow for fallbacks (look for val in
> > config
> > store X - if not there, look in Y, if not there look in Z. this is common
> > for
> > looking in user config first then falling back to system config ... but we
> > don't
> > do it value by value atm... but needing to be able to defined where those
> > config stores are would be important big-picture, with probably a default
> > of
> > system + user).
> >
> 
> This has probably very little to do with this specific interface, but would
> have to do with the config backend, i.e. elm_config or any preference
> module we come up with (if we ever do). Unless we want to expose options
> for such feedback policy... but that can be added later.
> 
> -- 
> Jean-Philippe André
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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" --------------
Carsten Haitzler - raster@rasterman.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

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