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 <d...@gurumeditation.it> 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
