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) > > > 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
