GNOME Bugzilla – Bug 754725
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,
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:
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.