Re: [E-devel] UnifiedAPI Namespace definition proposal
2018-02-24 16:47 GMT+01:00 Andrew Williams : > Just to follow up on this by way of “documentation on the website > handover”. Whether there is “consensus” or not there is still an underlying > issue. I exposed the namespaces that Daniel mentioned to make the website > API index more readable: https://www.enlightenment.org/develop/api/start I really think that the autogenerated documentation at this link is "cheating", it is grouping all the namespaces toghether (considering only the first level namespace). What you see in this page is not the real namespace hirarchy we currently have. The real one is expressed in my autogenerated doc at: http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:start > As you can see the “main class” of a namespace is often not in the > associated namespaces. This is because the way eolian namespaces work is > basically implicit and the class name (or last part of the fully qualified > name) is not part of the namespace - so Efl.Canvas is not within efl.canvas > namespace. > Indeed this is an issue that must be addressed (with tons of other issue wrt namespace hierarchy) > > This, in my unbiased-because-I’m-not-contributing-anymore needs to be > addressed and I think it would make life better for those who are binding > to other languages too. > > Andy > > On Sat, 24 Feb 2018 at 11:09, Davide Andreoli > wrote: > > > 2018-02-24 10:16 GMT+01:00 Vincent Torri : > > > > > On Fri, Feb 23, 2018 at 7:53 PM, Davide Andreoli < > d...@gurumeditation.it > > > > > > wrote: > > > > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa : > > > > > > > >> 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 > fe
Re: [E-devel] UnifiedAPI Namespace definition proposal
Just to follow up on this by way of “documentation on the website handover”. Whether there is “consensus” or not there is still an underlying issue. I exposed the namespaces that Daniel mentioned to make the website API index more readable: https://www.enlightenment.org/develop/api/start As you can see the “main class” of a namespace is often not in the associated namespaces. This is because the way eolian namespaces work is basically implicit and the class name (or last part of the fully qualified name) is not part of the namespace - so Efl.Canvas is not within efl.canvas namespace. This, in my unbiased-because-I’m-not-contributing-anymore needs to be addressed and I think it would make life better for those who are binding to other languages too. Andy On Sat, 24 Feb 2018 at 11:09, Davide Andreoli wrote: > 2018-02-24 10:16 GMT+01:00 Vincent Torri : > > > On Fri, Feb 23, 2018 at 7:53 PM, Davide Andreoli > > > wrote: > > > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa : > > > > > >> 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. > > >> > > > >> > > > >> > waiti
Re: [E-devel] UnifiedAPI Namespace definition proposal
2018-02-24 10:16 GMT+01:00 Vincent Torri : > On Fri, Feb 23, 2018 at 7:53 PM, Davide Andreoli > wrote: > > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa : > > > >> 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 > >> > enlightenment-devel@lists.sourceforge.net > >> > 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 > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > -- > > Check out the vibrant tech community on
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Fri, Feb 23, 2018 at 7:53 PM, Davide Andreoli wrote: > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa : > >> 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) 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 >> > enlightenment-devel@lists.sourceforge.net >> > 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 >> enlightenment-devel@lists.sourceforge.net >> 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 > enlightenment-devel@lists.sourceforge.net > 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
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Fri, Feb 23, 2018 at 7:00 PM, Daniel Kolesa wrote: > On Fri, Feb 23, 2018, at 19:42, Davide Andreoli wrote: [snip] >> Of course Eolian should help us to not make mistakes, but the real issue >> at this point is that there isn't a clear consensus of what the namespaces >> are and how they should be managed in bindings (that is the key point of >> this email) > > I don't really know what you mean by "there isn't a clear concensus"... this > has been discussed numerous times and as far as I know there isn't anything > left unsolved. Indeed. I had to modify C++ generation because it was consensus that allowing classes and namespaces to have the same name a good thing for C. [snip] Regards, -- Felipe Magno de Almeida -- 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
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Fri, Feb 23, 2018, at 19:42, Davide Andreoli wrote: > 2018-02-22 17:02 GMT+01:00 Carsten Haitzler : > > > On Sun, 18 Feb 2018 10:28:54 +0100 Davide Andreoli > > > > said: > > > > hey dave. i had this marked... :) > > > > > 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. > > > > a read of the below... why can't you just have a single Efl namespace? I'm > > not > > sure I get the need for complex namespaces here... you have classes... and > > they > > can all be within the EFl namespace... :) any reason you can't do this? > > doesn't > > this simplify things? > > > > I can layout the classes as I wish in python (with manual intervention on > the generator), > what I'm trying to avoid is to rename the full name of the classes, IMO one > of the > key point of Eo/Eolian is that we will have consistent bindings for > different languages. > > > > > > > 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? > > > > Well we are pretty much using a tree structure for the efl classes, so i > > think > > this applies, but something in the Efl.Canvas namespace could inherit a > > class > > or interface from Efl.Elephant does that bother you? > > > This is not a technical problem in python, I can live with that (also if it > smell to me > like a wrong layout of our Eo classes hierarchy) > > > > > it's still > > > > obj.methodname() > > > > or similar... the namespace is only relevant when creating the object ... > > i.e. > > its class and ... can't that just be EFl.something_something_blah ? educate > > me... i know nothing about python here so i doubt i can offer a lot of > > advice > > here... (which is why i haven't jumped in to answer this). > > > > hmm, I can do that flat namespace layout but it seems wrong to me :) > > for example the Efl.Animation.Player.Running_Event_Info structures will > begun the Animation_Player_Running_Event_Info class in the Efl namespace. > > In this way I'm totally loosing the meaning of namespaces! > > > > > > > > > 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) > > > > this is going to be hard to enforce unless eolian enforces it and tells us > > there is a conflict... :) > > > > Of course Eolian should help us to not make mistakes, but the real issue > at this point is that there isn't a clear consensus of what the namespaces > are and how they should be managed in bindings (that is the key point of > this email) I don't really know what you mean by "there isn't a clear concensus"... this has been discussed numerous times and as far as I know there isn't anything left unsolved. > > > > > > > > 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) > > > > > > > > > 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 > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code,
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Fri, Feb 23, 2018, at 19:53, Davide Andreoli wrote: > 2018-02-23 12:03 GMT+01:00 Daniel Kolesa : > > > 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... Oh, I see. Probably makes sense to introduce a check to make sure namespace names don't conflict with declaration names then. > > > > > > > > > > > > > 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 > > > enlightenment-devel@lists.sourceforge.net > > > 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 > > enlightenment-devel@lists.sourceforge.net > > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenmen
Re: [E-devel] UnifiedAPI Namespace definition proposal
2018-02-22 17:02 GMT+01:00 Carsten Haitzler : > On Sun, 18 Feb 2018 10:28:54 +0100 Davide Andreoli > > said: > > hey dave. i had this marked... :) > > > 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. > > a read of the below... why can't you just have a single Efl namespace? I'm > not > sure I get the need for complex namespaces here... you have classes... and > they > can all be within the EFl namespace... :) any reason you can't do this? > doesn't > this simplify things? > I can layout the classes as I wish in python (with manual intervention on the generator), what I'm trying to avoid is to rename the full name of the classes, IMO one of the key point of Eo/Eolian is that we will have consistent bindings for different languages. > > > 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? > > Well we are pretty much using a tree structure for the efl classes, so i > think > this applies, but something in the Efl.Canvas namespace could inherit a > class > or interface from Efl.Elephant does that bother you? This is not a technical problem in python, I can live with that (also if it smell to me like a wrong layout of our Eo classes hierarchy) > it's still > > obj.methodname() > > or similar... the namespace is only relevant when creating the object ... > i.e. > its class and ... can't that just be EFl.something_something_blah ? educate > me... i know nothing about python here so i doubt i can offer a lot of > advice > here... (which is why i haven't jumped in to answer this). > hmm, I can do that flat namespace layout but it seems wrong to me :) for example the Efl.Animation.Player.Running_Event_Info structures will begun the Animation_Player_Running_Event_Info class in the Efl namespace. In this way I'm totally loosing the meaning of namespaces! > > > 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) > > this is going to be hard to enforce unless eolian enforces it and tells us > there is a conflict... :) > Of course Eolian should help us to not make mistakes, but the real issue at this point is that there isn't a clear consensus of what the namespaces are and how they should be managed in bindings (that is the key point of this email) > > > 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) > > > > > > 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 > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > Carsten Haitzler - ras...@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
Re: [E-devel] UnifiedAPI Namespace definition proposal
2018-02-23 12:03 GMT+01:00 Daniel Kolesa : > 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... > > > > > > > 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 > > enlightenment-devel@lists.sourceforge.net > > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Thu, Feb 22, 2018, at 19:42, Mike Blumenkrantz wrote: > It seems there is some confusion both in this mail and in the community > about how the interfaces API works, partly due to how .eo files work and > the current syntax that is used. Some changes are in progress to make > things more clear, and there will be more info on this soon. > > Regarding the points that you have raised, it's important to separate the > concepts of "EFL API" and "EFL API implementation". The former is the > specification in the eo files while the latter is the code which is created > using an eolian generator for a given language. > > This is a significant detail because the EFL API does not vary (as there is > only one instance of it) while the EFL API implementation is simply the > interpretation of the EFL API within the confines of the implementation > language. This means that, for example, the Python implementation of the > EFL API is "whatever works best for Python users" and not "the exact > copying of the EFL API". The key point in this is to create a > language-based implementation of the EFL API which can correlate to the > documentation for EFL API functionality such that users of the language are > able to effectively develop applications based on the docs. > > As an example of this, there is an EFL API namespace > "Efl.Canvas.Animation". In C, however, this is implemented with the API > namespace efl_animation, omitting "canvas" entirely. Other languages may > choose to retain "canvas" in their implementation if it is necessary or > relevant, but this is not a requirement. Well, not exactly. The eo file definitions *are* the actual definitions of the API, which bindings should follow, though they can adjust their output in order to make things idiomatic for that language. Being able to rename C APIs is a completely different matter, C has no actual namespaces and therefore C doesn't have to always match the basic eo file definitions 100% (through the means currently provided by eo_prefix etc). > > On Thu, Feb 22, 2018 at 8:10 AM 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? > > > > 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) > > > > > > 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 > > enlightenment-devel@lists.sourceforge.net > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] UnifiedAPI Namespace definition proposal
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. > > > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Sun, 18 Feb 2018 10:28:54 +0100 Davide Andreoli said: hey dave. i had this marked... :) > 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. a read of the below... why can't you just have a single Efl namespace? I'm not sure I get the need for complex namespaces here... you have classes... and they can all be within the EFl namespace... :) any reason you can't do this? doesn't this simplify things? > 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? Well we are pretty much using a tree structure for the efl classes, so i think this applies, but something in the Efl.Canvas namespace could inherit a class or interface from Efl.Elephant does that bother you? it's still obj.methodname() or similar... the namespace is only relevant when creating the object ... i.e. its class and ... can't that just be EFl.something_something_blah ? educate me... i know nothing about python here so i doubt i can offer a lot of advice here... (which is why i haven't jumped in to answer this). > 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) this is going to be hard to enforce unless eolian enforces it and tells us there is a conflict... :) > 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) > > > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@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
Re: [E-devel] UnifiedAPI Namespace definition proposal
It seems there is some confusion both in this mail and in the community about how the interfaces API works, partly due to how .eo files work and the current syntax that is used. Some changes are in progress to make things more clear, and there will be more info on this soon. Regarding the points that you have raised, it's important to separate the concepts of "EFL API" and "EFL API implementation". The former is the specification in the eo files while the latter is the code which is created using an eolian generator for a given language. This is a significant detail because the EFL API does not vary (as there is only one instance of it) while the EFL API implementation is simply the interpretation of the EFL API within the confines of the implementation language. This means that, for example, the Python implementation of the EFL API is "whatever works best for Python users" and not "the exact copying of the EFL API". The key point in this is to create a language-based implementation of the EFL API which can correlate to the documentation for EFL API functionality such that users of the language are able to effectively develop applications based on the docs. As an example of this, there is an EFL API namespace "Efl.Canvas.Animation". In C, however, this is implemented with the API namespace efl_animation, omitting "canvas" entirely. Other languages may choose to retain "canvas" in their implementation if it is necessary or relevant, but this is not a requirement. On Thu, Feb 22, 2018 at 8:10 AM 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? > > 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) > > > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
