> -------- Original Message -------- > Subject: [E-devel] Interfaces API not in EFL namespace > Local Time: December 8, 2017 10:35 AM > UTC Time: December 8, 2017 6:35 PM > From: a...@andywilliams.me > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > > Hi, > > I've been going through our API documentation generation (for Eo API) and I > found some interesting numbers. We all know there is a lot to do in terms > of porting legacy to Eo API but I found a lot of API that is in Eo but is > not in the Efl namespace (i.e. Ecore / Elm etc) which I assume will also > need to be ported. > > The total number of "legacy eo" classes and types are as follows (with > percentage of total in each category) > > === CLASS SECTION: 442 === > > Classes: 157 (44%) > Interfaces: 3 (3.5%) > Mixins: 8 (24%) > Events: 274 (48%) > > === TYPE SECTION: 807 === > > Aliases: 62 (85%) > Structs: 46 (52%) > Struct fields: 71 (35%) > Enums: 92 (48%) > Enum fields: 534 (40%) > > Or to summarise 43% of the Eo definitions are not in the Efl namespace. > This is a lot of additional work to the new class creation - do we have > tickets to track this all as well?
We have ported basically every object we had to Eo, but this doesn't mean they will be part of the new Eo exposed API. They can stay legacy forever on top of Eo API. This provide for additional safety and better integration between legacy object and new Eo object. I have to update the ticket tracking all development for the interface some time during the weekend. This should reflect what we intend to make part of the new API. Cedric ------------------------------------------------------------------------------ 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
