On Mon, Jun 30, 2014 at 08:58:58AM -0700, Thiago Macieira wrote: > Em seg 30 jun 2014, às 11:10:28, Jędrzej Nowacki escreveu: > > What about creating an intermodule api, which would stay private from a > > user point of view. We can agree on some rules, like for example not > > removing symbols between patch releases, having some test coverage? > > We can also call it "unsupported public API". But yes, if we do this, then > some BC rules need to apply and we should have some minimal testing.
Following the discussion on this thread I'm trying to get rid of QtWebEngine's dependency on qtbase and qtdeclarative private headers/symbols, and I'm hitting one case where we might not necessarily want the API to be public [1]. Intermodule API doesn't have to be as robust as public API and it would be nice to keep it that way. Concretely, what would be the best way to define and maintain such an intermodule API? In the change I'm simply marking public functions as \internal for the documentation, but this might not be enough to discourage applications from using it. Another option I see is to name them _q_something as we already do for other publically exported private functions. Or maybe somebody has other ideas, what do you think? 1: https://codereview.qt-project.org/91132 Cheers, Jocelyn _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
