On Fri, Feb 23, 2018, at 19:42, Davide Andreoli wrote: > 2018-02-22 17:02 GMT+01:00 Carsten Haitzler <ras...@rasterman.com>: > > > On Sun, 18 Feb 2018 10:28:54 +0100 Davide Andreoli <d...@gurumeditation.it > > > > > 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)
Advertising
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, 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 ------------------------------------------------------------------------------ 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
