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)

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

Reply via email to