On 04/25/2014 01:25 PM, Jean-Philippe André wrote: > 2014-04-25 19:11 GMT+09:00 Cedric BAIL <cedric.b...@free.fr>: > >> Hello, >> >> On Fri, Apr 25, 2014 at 11:07 AM, Jean-Philippe André <j...@videolan.org> >> wrote: >>> 2014-04-25 17:49 GMT+09:00 Stefan Schmidt <ste...@datenfreihafen.org>: >>>> Triggered from the Evas 3D commits I talked with jpeg about having a >>>> flag that controls if unstable API's are enabled or not. >>>> >>>> This would allow us to have big new features, I have Evas 3D in mind >>>> here, in the coe base but have it hidden behind an BETA API flag so we >>>> are not bound to stick with the API until we are happy with it. >>>> >>>> It should not be used to get all kind of crap into the code base >>>> though. I see it as a mechanism to give the code time to mature for >>>> one more release cycle. If we are happy with the API we will remove >>>> the BETA guards around it. On the other hand if we still are not happy >>>> with it after 3 months in the new cycle we can as well remove it from >>>> the master branch and give it more love before it will go in again. >>>> >>>> Jpeg was thinking about it for new functionaliyt of an existing API. I >>>> guess we could handle this as well. >>> I was thinking of my "filters" API which was hidden behing EO and BETA >>> flags for EFL 1.9. >>> But since we now actually use Eo with Eolian, the API itself is >>> auto-generated. >>> >>> So, we'd need Eolian to not generate some bindings for the legacy API. >>> Add a @beta flag or something in the EO file. >>> >>> Then, only the EO binding is generated, and the legacy API is not. >>> But I'm not sure if we can hide the symbols in the final library, since >> EO >>> now uses real functions as entry points? >> Right now I do prefer that we do compile the code and require >> application that want to use it to explicitly require the flag. I see >> two reasons for it, first it prevent code rotting (obviously being >> compiled by everyone is better). Second it doesn't require a special >> package to try the beta API. Also for this release all Eo API is still >> in alpha with high risk of seeing its ABI and API broken for next >> release. It would means no binding at all for this release. So nobody >> will start playing with it. >> >> Also what would be the value of not compiling the code ? It will >> increase our code complexity and the chance to accidentally break >> something. >> >> Maybe I wasn't clear enough... I never mentionned not compiling the code. > Only disabling the API. > Apps that want to use it must #define EFL_BETA_API or something like that > to use it. And then they know it's unstable. > > Which basically means (now) it should only be part of EO APIs and not in > legacy headers. > > I agree with you that the code should always be compiled, quietly tested, > and if possible also used by core developers. > > Cheers, > You can also #ifdef ...BETA... inside the .h that includes the .eo.h/.legacy.h, e.g elm_gengrid.h.
------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
