On Sun, Jan 14, 2018 at 9:18 AM, Andrew Williams <a...@andywilliams.me> wrote:
> 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. > Any proposal? Efl.Canvas -> Efl.Canvas.Canvas would be fine to me, but then need the C names to remain unchanged (EFL_CANVAS_CLASS, efl_canvas_blah_call, etc...) Same for Efl.Selection. Efl.VG has been mentioned too, does it belong to Efl.Gfx? Should Efl.Vg itself be Efl.Vg.Object / Efl.Vg.Node? Or Efl.Gfx.Vector.Node? Same for Animation & Interpolator, Player & Playable, Gesture, etc... Should we have a "Util" namespace for non ui common tools, like Interpolator, Observable/Observer, Config, Vpath?, Whatever the solution I doubt we can find a solution that works beautifully in all languages. C has its own restrictions unless we accept awkward & long names (then how would that be any better than legacy?) while various languages have their own issues. C++ and C# are now fine with having a As a side note, the documentation lacks a section "these classes use / implement / inherit from this class / interface". > Thanks, > Andy > > On Sat, 13 Jan 2018 at 10:45 Davide Andreoli <d...@gurumeditation.it> > wrote: > > > 2018-01-11 6:18 GMT+01:00 Jean-Philippe André <j...@videolan.org>: > > > > > 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()? > > > > > > > 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 > > > 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 > > > > > -- > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- 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
