GNOME Bugzilla – Bug 754725
Introspectable API
Last modified: 2018-09-21 13:50:17 UTC
As for libgda, there are some structures witch are hard to introspect, making libgda out to be fully useful on other languages supporting GObject Introspection. Using, as a guide, https://wiki.gnome.org/Projects/GObjectIntrospection/WritingBindingableAPIs and taking the opportunity to libgda 6.0, to break API in order to be more introspectable friendly, will be great to improve. This bug, should depend on others, when an API break/improve should take take place in order to get better introspectable API. In most cases, we should hide most structs members and add API to get access to them, making easy to GObject Introspection and its supported languages, to access most advanced libgda features.
After first shot on API, I found the following items. For each item a bug report should be created and make this depends on it. _GdaAttributesManager - No GObject _GdaBlobOp - remove members in GObject definition _GdaDsnInfo - No accessors make opaque _GdaProviderInfo - No accessors make opaque GdaServerProviderConnectionData - Make opaque GdaDiff - No accessors _GdaDataModelBdbClass - Check virtual methods _GdaDataModelIface - Rename virtual methods GdaDataSelectInternals - No accessors make opaque _GdaDataSelect - Remove members in GObject defintion GdaMetaStoreChange - No accessors make opaque GdaMetaContext - No accessors make opaque GdaMetaTable - No accessors make opaque GdaMetaView - No accessors make opaque GdaMetaDbObject - No accessors make opaque GdaMetaTableColumn - No accessors make opaque GdaMetaTableForeignKey - No accessors make opaque GdaServerOperationNode - No accessors make opaque GdaServerProviderHandlerInfo - No accessors make opaque GdaServerProviderBase - No accessors make opaque GdaServerProviderMeta - No accessors make opaque GdaServerProviderXa - No accessors make opaque _GdaServerProviderClass - Remove members on class definition _GdaSetNode - Make opaque _GdaSetGroup - Make opaque _GdaSetSource - Make opaque _GdaSet - Remove members on GObject definition _GdaSqlRenderingContext - No accessors make opaque _GdaTransactionStatusEvent - No accessors make opaque _GdaTransactionStatus - Remove members on GObject definition GdaSList - Reimplement GdaGeometricPoint - No accessors make opaque GdaNumeric - Make opaque GdaTime - No accessors make opaque GdaTimestamp - No accessors make opaque GdaBlob - No accessors make opaque _GdaXaTransactionId - No accessors make opaque
For "Remove members on GObject", no fields should be on GObjec struct defintion and tries to install private members as for modern GObject definitions.
For "No accessors make opaque", the struct members should be opaque no public and one method to set/get should be added, including a new and free functions.
For "Make opaque" in previous iterations, a GSEAL macro was added to hide members and find when the code access directly to the member not the public API. Some structs already have get/set accessors and in most cases they can be make opaque.
Do we really need to make stuff beginning with an underscore opaque? Maybe it's my current Python obsession, but they feel "private" stuff to me. If not, maybe we should also remove that leading underscore.
This are just *marks*. If you search them on headers, you'll find the corresponding names without underscore.Sorry for that. In all cases no changes on typedef struct is required, just move it's content to C file to make it opaque and remove them from public API. But first add get/set accessors methods. When done we should port other parts in the code to use them no struct ones. After porting, witch will produce a huge patch, we should run all unit tests to insure correct porting. We can use GSEAL macro to port member by member, method by method, and produce smaller patches.
Please check resolution of Bug #754263 and commit: https://git.gnome.org/browse/libgda/commit/?id=db94bed1bdca380f2106ff3b08a9d391e2964590 and commit: https://git.gnome.org/browse/libgda/commit/?id=afa7e5f6a31dd2fe691adb98001254e4ab291e6c This is the work we need to do to seal all other structs out there: 1) File a bug and make this bug to depend on it. Then: a) Public struct set as obscure (typedef struct _GdaBinary GdaBinary) b) C source define struct and its members (struct _GdaBinary) c) Create a *_new function and make sure the object could be created without paramenters, unless is strictly necesary (gda_binary_new) d) Add accessors to the struct members (gda_binary_get_data) e) Add setters to struct members, making sure they can be individual or in group (gda_binary_set_data) f) Patch all occurrence in the source code trying to access struct members. This is easy to detect because compilation will fail due to unable to access struct members. The hard part is to ensure you translate correctly existing code to new one, i.e., gda_binary_set_data() requires pointers to data, then you should set up it before to call it, while in some cases old code sets data directly. g) Make sure you have a make check working without errors h) Propose a patch or in case you have commit access, promote your patch to be accepted by Vivien Malerba. 2) Propose to close your initial filed bug
I would like to lead to Vivien Malerba, changes on class and object structs with public members (no functions), because they are more delicate.
Filed all bugs this depends on, in order to track work done.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libgda/issues/84.