Bug 8967 - GLib.Object.GetProperty and GLib.Object.SetProperty are protected
Summary: GLib.Object.GetProperty and GLib.Object.SetProperty are protected
Status: NEW
Alias: None
Product: Gtk#
Classification: Mono
Component: gtk-sharp ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-12-16 10:20 UTC by Tomasz Melcer
Modified: 2016-06-22 21:52 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 8967 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Tomasz Melcer 2012-12-16 10:20:57 UTC
GLib.Object.GetProperty and GLib.Object.SetProperty are protected in Gtk#, whereas their equivalents in other languages, including the original C API, make those calls public (see. e.g. http://www.gtk.org/api/2.6/gobject/gobject-The-Base-Object-Type.html#g-object-set).
Comment 1 Antonius Riha 2014-09-07 04:43:06 UTC
The decision to make them protected was deliberately made as they were originally public and then made protected in this commit: https://github.com/mono/gtk-sharp/commit/1a1f5e1702dd7b9b67ef4973577f48e806e83d7b. The commit author didn't provide a reason for this change though.

A possible reason might be type safety as described by the java-bindings reference page (http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/glib/Object.html):
"The use of a String property name is, of course, insanely type-unsafe, which is why we don't expose it in our public API. Luckily, though, in general it is not necessary to use this at all, as most GObjects provide convenience methods for such things, and should be used in preference wherever available."

However, if you still need access to them, you can always create a subclass and add public access (as long as it's not a sealed class).

I personally would vote to close this issue as invalid, because it would open the doors for unsafe programming and this is just not what C# programming is about.
Comment 2 Tomasz Melcer 2014-09-07 07:37:11 UTC
Thank you for your answer. I interpret it as follows:

* It is not your intention to expose all Glib features.

* You believe you know better what programmers who use your libraries should be allowed to do.

If I recall correctly, I submitted this bug report because I needed to have full Glib object introspection capabilities for my project (a reactive framework on top of GTK). Subclassing every single GTK class is not an option in this case obviously, as I would need to also work with objects created outside of my project.

I fully understand your point of view, even if it makes building certain classes of libraries impossible. Thankfully, I haven't wasted much time on the idea and—given how much time has passed since then, I'm sure you'll understand that I'm not interested in it anymore. Therefore I'm fine with closing this issue, if you will.
Comment 3 Antonius Riha 2014-09-07 08:21:12 UTC
Although it's not relevant for you anymore, I'd like to add that in this case you might had been able to leverage C#'s reflection capabilities to achieve this.

I'd also like to clarify that I was just posting observations and stating my opinion (and the opinion of the java-bindings dev I cited) in comment #1. I'm not a member of the core dev team of mono/gtk-sharp, just an occasional contributor. However, I *think* there have been design decisions made that favour some use cases over others, namely desktop app development vs. building libraries that deeply integrate with glib-sharp (which doesn't necessarily mean that's impossible to do that, but not as straight forward as app development).

I also think it's sad that bug reports in the gtk-sharp module remain unattended more often than not. In an attempt to change that, I'm going through some of them right now:)

I don't have edit rights in this bug tracker, so you might close it yourself or wait for someone who has.