On Thu, 11 Jan 2018 14:18:21 +0900 Jean-Philippe André <j...@videolan.org> said:
> Hi Dave, > > On Thu, Jan 11, 2018 at 7:43 AM, Davide Andreoli <d...@gurumeditation.it> > wrote: > > > 2018-01-08 19:52 GMT+01:00 Cedric Bail <ced...@ddlm.me>: > > > > > Hi Dave, > > > > > > > -------- Original Message -------- > > > > Subject: [E-devel] Eo/Eolian namespace definition > > > > Local Time: January 7, 2018 9:28 AM > > > > UTC Time: January 7, 2018 5:28 PM > > > > From: d...@gurumeditation.it > > > > To: Enlightenment <enlightenment-devel@lists.sourceforge.net> > > > > > > > > Hi all, > > > > > > > > I'm playing again with eolian and python, and I'm facing an issue with > > > > regards class names and namespaces separation (I already raised this in > > > the > > > > past) > > > > > > > > A first intro to python namespaces (I think apply to any other > > high-level > > > > language): > > > > > > > > - in py every class must live in a given namespace and you use the > > class > > > as: > > > > from <namespace> import <class> > > > > - every namespace in python is a separate .so file > > > > > > > > The basic question is: > > > > is the Efl.Text (interface) inside the Efl.Text namespace? > > > > do I need to put the Text interface inide the Efl.Text .so file? > > > > > > > > NO) if the resonse is no, then in python will become: > > > > from efl.ui import Button > > > > from efl import Text > > > > from efl.text import Font > > > > > > > > this feels wrong to me, as Text is not in the text namespace > > > > > > > > YES) if the response is YES: > > > > from efl.ui import Button > > > > from efl.text import Text > > > > from efl.text import Font > > > > Would interfaces need to be imported in Python? > Can't we just use obj.font_foo() and obj.text_bar()? > > from efl.text import Text > With a Text obj -> obj.font_foo()? what you said above. this should come out like c++ with methods on objects. the only thing that would be globals that would need the above namespaces are class funcs... and those are pretty rare. > > > > this one seems correct to me, but this means that the full name of the > > > Text > > > > class should be Efl.Text.Text (this is a must in python, and probably > > in > > > > all other langs) > > > > > > I think that Text is maybe a bad example as it might be best to move it > > to > > > the Efl.Gfx namespace. In general I think our Efl top namespace is to > > > crowded and would be better cleaned up. I am guessing this would solve > > many > > > problem for python, no ? In general, do you have rules for naming and > > > namespaces that you would like us enforcing ? If we had, we could enforce > > > them in eolian. > > > > > > > For the moment the only problem I found for python is that a name-space > > cannot have the same name as a class, f.e. Efl.Text (class) and Efl.Text > > (namespace) cannot be made available to python with this exact names. I > > already "fixed" this issue using lowercased namespace names like: efl.Text > > (class) and efl.text.* (namespace). At the end this is a no-problem for py > > because lowercased namespaces is the raccomended standard in python, so it > > fit well. > > > > Yes, this is what's done for C++ and C# as well. > That was the intent since we started allowing some classes to have the same > name as a namespace (eg. efl.Canvas and efl.canvas.Object). > > > The main intent of this thread is to try to define and standardize the way > > we are naming classes, in particular wrt to the namespace hierarchy. > > I understand that coding in C this seems a no-problem, but for languages > > that support/require namespaces this must be defined cleanly, at the eolian > > level; > > to ensure that we will produce/generate conformant and standardized > > namespace hierarchy in differetn bindings. > > I mean: the Button class should be in the same namespace (Efl.Ui) in all > > different bindings we will produce. > > > > That is the intent. And in C we probably could (ab)use eo_prefix more to > have nice names despite long namespaces. > > > TBH I'm really surprised that a plan has not been done on this, I cannot > > really undestand how we expect to create a consistent and clean API if > > everyone choose "quite random names" (exageration intended and for joking) > > imo we really need to write down the full hierarchy (also with planned > > classes) and discuss on that ! > > > > Believe me or not, we've actually been trying to have consistent names :) > > I was actually assuming the generated doc would be a good way to verify > that the names are good. > The amazing work that's been done on the docs can help us already :) > https://www.enlightenment.org/develop/api/start > > Should we open a phab ticket and list names that are thought to be > problematic? > Andy suggested to at least try to reduce the number of top-level namespaces. > Some namespaces (Efl.Ui) are also quite messy. > > -- > Jean-Philippe André > ------------------------------------------------------------------------------ > 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
