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

Reply via email to