2018-01-11 6:18 GMT+01:00 Jean-Philippe André <[email protected]>: > Hi Dave, > > On Thu, Jan 11, 2018 at 7:43 AM, Davide Andreoli <[email protected]> > wrote: > > > 2018-01-08 19:52 GMT+01:00 Cedric Bail <[email protected]>: > > > > > 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: [email protected] > > > > To: Enlightenment <[email protected]> > > > > > > > > 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()? >
nono, in py you need to import the simbols you want to explicity use. C objecs that implement the Text interface will translate to Python in an object that inherit from the Text interface, thus all the interface method/properties will be available in the obect itself. So there is no need to import the Text interface to just use an object that implement it, but you need to import the iface if you want (fe) to create a new class that implement that interface (not sure if this will make sense in practice) or you need to use that name for other means, maybe you want to check if a given object implement a specific interface: from efl.text import Text ... if isinstance(obj, Text): blah, blah In this case you need to import the interface as you are using it's name. > > from efl.text import Text > With a Text obj -> obj.font_foo()? > > > > > > > > > > > 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). > If all the bindings we have written so far need this lowercase-on-namespaces hack then It's probably correct to lowercase them directly in eo files, so that Efl.Ui.Button will become efl.ui.Button This way we will have: * consistent names between different languages * no more clashes between namespaces and class names. * lowered namespaces also seems more readable to me, as it give more weight to the class name and a bit less to the namespace. > > > 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 Yes, that page should be our primary reference... but note that namespaces on that page are not the original ones, they are somehow manipulated to make the page more readable (IMO that page is "hiding a bug") for example, in the start page, the Efl.Text interface is inside the Efl.Text namespace, while the correct place (giving the actual name) is in the Efl namespace Tomorrow I will generate and post a hierachy of namespaces/classes as they will come up in bindings (without doing any manipulations), so that we can discuss on that one. > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
