After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754725 - Introspectable API
Introspectable API
Status: RESOLVED OBSOLETE
Product: libgda
Classification: Other
Component: Vala bindings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Daniel Espinosa
gnome-db Maintainers
Depends on: 754263 754707 754805 765384 765392 765743 765744 765745 765746 765747 765748 765749 765750 765751 765753 765754 765755 765756 765757 765758 765759 765760 765761 765762 765763 765764 765765 765766 765767 765768 765769 765770 765771 765772 765774 765775 765776 765777
Blocks:
 
 
Reported: 2015-09-08 13:42 UTC by Daniel Espinosa
Modified: 2018-09-21 13:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Espinosa 2015-09-08 13:42:18 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.
Comment 1 Daniel Espinosa 2015-09-08 23:35:17 UTC
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
Comment 2 Daniel Espinosa 2015-09-08 23:36:33 UTC
For "Remove members on GObject", no fields should be on GObjec struct defintion and tries to install private members as for modern GObject definitions.
Comment 3 Daniel Espinosa 2015-09-08 23:37:46 UTC
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.
Comment 4 Daniel Espinosa 2015-09-08 23:40:02 UTC
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.
Comment 5 Gergely POLONKAI 2015-09-09 05:43:52 UTC
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.
Comment 6 Daniel Espinosa 2015-09-09 11:37:13 UTC
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.
Comment 7 Daniel Espinosa 2016-04-21 15:42:19 UTC
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
Comment 8 Daniel Espinosa 2016-04-21 19:53:11 UTC
I would like to lead to Vivien Malerba, changes on class and object structs with public members (no functions), because they are more delicate.
Comment 9 Daniel Espinosa 2016-04-28 19:59:22 UTC
Filed all bugs this depends on, in order to track work done.
Comment 10 GNOME Infrastructure Team 2018-09-21 13:50:17 UTC
-- 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.