On Sun, 27 Apr 2014 07:54:35 +0300 Daniel Zaoui <daniel.za...@samsung.com> wrote:
> 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. Actually we already had EFL_BETA_API_SUPPORT. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
