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