| Summary: | [0.11] Use GSEAL (or similar) on TpConnectionManager's public struct fields | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Murray Cumming <murrayc> |
| Component: | tp-glib | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | xclaesse |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://cgit.freedesktop.org/~smcv/telepathy-glib/log/?h=seal | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 24116, 49384 | ||
| Bug Blocks: | 31668 | ||
|
Description
Murray Cumming
2008-08-13 03:05:23 UTC
> There should really be nice get/set functions Getters would be sufficient, all the public fields are (documented to be) read-only. > and the struct's implementation should be hidden We can't hide it in terms of API (that would be an API break), but we can hide it from the docs and deprecate access to it. Maybe GSEAL can be used here? G_SEAL() is a way to deprecate use of API that you can't break. But as far as I know telepathy-glib is not really API-stable anyway, so we can just hide the struct implementation. telepathy-glib is API- and ABI-stable in the sense that we do not break existing functionality. It's unstable in the sense that new functionality is frequently *added*. Is there no plan to do a parallel-install version eventually? Has that been ruled out? (In reply to comment #5) > Is there no plan to do a parallel-install version eventually? The operative word is "eventually". We do not plan to break ABI soon. Since this bug was filed, function-based accessors have been added for various struct members (although possibly not all of them). My wip-seal branch contains some unfinished work: adding a TP_SEAL macro, and starting to use it for structs. (Simon removed his branch.) Setting a blocking tp-glib 1.0 meta bug, should we consider removing all fields from public structs like gtk3 did? (In reply to comment #8) > Setting a blocking tp-glib 1.0 meta bug, should we consider removing all fields > from public structs like gtk3 did? Yeah, let's. Of the GObject structs, I think this just means TpProxy and TpConnectionManager. Among non-GObjects, TpConnectionManagerProtocol can be deprecated entirely, TpConnectionManagerParam should be sealed (and get a shorter typedef!), and I think the rest are deliberately public (but I'll check through them). The branch depends on my branch from Bug #49384, for _TP_COMPILATION. I don't think we want to seal parent and priv fields of GObject struct, since sealed fields are to be removed in 'next'. TpBaseConnection has also fields to seal. Merged Simon's seal-more branch into master. With few changes: - Skipped unrelated "Deprecate tp_list_connection_managers" and "TpConnectionManagerProtocol: deprecate in favour of TpProtocol" for now because tp-glib itself is still using those APIs. - Squashed "Don't _TP_SEAL parent or priv" into relevant commits. - Added "Since: 0.UNRELEASED" to new functions and added them into the doc. (In reply to comment #13) > - Skipped unrelated "Deprecate tp_list_connection_managers" and > "TpConnectionManagerProtocol: deprecate in favour of TpProtocol" for now > because tp-glib itself is still using those APIs. I've made the fix to stop using them internally and pushed them as well now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.