2018-02-24 10:16 GMT+01:00 Vincent Torri <[email protected]>: > On Fri, Feb 23, 2018 at 7:53 PM, Davide Andreoli <[email protected]> > wrote: > > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa <[email protected]>: > > > >> On Thu, Feb 22, 2018, at 14:05, Davide Andreoli wrote: > >> > Hi all, > >> > > >> > I'm working again on autogenerated python bindings for efl UnifiedAPI > but > >> > I'm quite blocked by the lack of namespace definitions in eo/eolian. > >> > > >> > This is a noproblem in C and any other language without proper > >> namespacing, > >> > but for the langs that provide namespaces (like python and many > others) > >> > this need to be defined in some way. > >> > > >> > First of all we need to define what a namespace is, and define some > rules > >> > for them. Then we should implement something in Eolian so that every > >> > different bindings can be generated with the same namespace hierarchy. > >> > > >> > Currently I'm assuming that the namespace of an object (class or > >> typedecl) > >> > is its full name without the last part, fe the Efl.Canvas.Object live > in > >> > the Efl.Canvas namespace. Is this correct? is this what we want? > >> > >> This is exactly correct. If you look at the Eolian API, you can even > >> retrieve the namespaces using the namespaces_get functions. > >> > >> > > >> > As for the rules we should define some, I have two on my mind atm: > >> > 1. (definition) The namespace of an object is it's full name without > the > >> > last part (mybe lowercased?) > >> > 2. A namespace cannot have the same name of another eo object > (classes, > >> > enums, typedefs, aliases, etc) > >> > > >> > The #2 is mandatory in python. I can workaround this in my generator > by > >> > lowercasing the namespaces (fe: efl.canvas.Object), but seems to me > that > >> > having 2 different things (a class and a namespace) with the same > name is > >> > confusing for everyone and probably will not work for > languages/systems > >> > without a case-sensitive filesystem (thinking about windoz here) > >> > >> I don't see what filesystems have to do with this, but I'm not exactly > >> opposed to introducing the rule. > >> > > > > In python a tree of namespaces is created on the filesystem using a > folder > > for each namespace, and > > in that folder there is a file for each class (more or less). To > implement > > the Efl namespace I must > > create a folder called Efl, and the Efl.Canvas namespace is a folder > inside > > the Efl Folder: > > > > Efl (the namespace, a folder) > > -> Canvas (the namespace, a folder inside the Efl folder) > > -> Canvas (the class, a file inside the Efl folder) > > > > This is just not going to work in python. > > > > I can workaround lowering the namespaces as: > > > > efl (the namespace, a folder) > > -> canvas (the namespace, a folder inside the efl folder) > > -> Canvas (the class, a file inside the efl folder) > > > > This will work on linux, no idea if it will work on windoz... > > It will not. The names must be different (noncase sensitive) > > maybe canvas_ns for the namespace on Python ? Or a subfolder named > Namespaces where are the namespaces (just ideas, i don't know if it is > feasible) >
the first suggestion will look very ugly while the second is not feasible. But note that I'm not searching for python-related solutions, I'm trying to help the guys that are working on the UnifiedAPI to create something that will works for namespace-aware languages. > > Vincent > > > > > > >> > >> > > >> > > >> > To better understand what I'm speaking about please give a look at: > >> > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:start > >> > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop: > api:namespaces > >> > > >> > Those pages are automatically generated, are NOT python related, and > >> should > >> > serve as a reference for the UnifiedAPI work in progess, they provide > a > >> > clean view of the current state of our new API. > >> > > >> > > >> > waiting for comments and ideas > >> > davemds > >> > ------------------------------------------------------------ > >> ------------------ > >> > 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 > >> > [email protected] > >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > >> ------------------------------------------------------------ > >> ------------------ > >> 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 > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > ------------------------------------------------------------ > ------------------ > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------ > ------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
