Hi, Thanks for pointing out the bug in the API docs that have been generated. I have now updated this to show the true impact of incomplete namespaces. Go to https://www.enlightenment.org/develop/api/start now and you will see a very long list of classes and interfaces at the top which are not part of a larger namespace.
This does look more confusing (for example: Efl.Canas is not in the same space as Efl.Canvas.Group) but it highlights this issue well. We should come up with a method for fixing these in a way that our bound languages will be happy with too. Thanks, Andy On Sat, 13 Jan 2018 at 10:45 Davide Andreoli <[email protected]> wrote: > 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 > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ 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
