GNOME Bugzilla – Bug 686542
Vala is too strict when checking derived properties
Last modified: 2018-05-22 14:31:31 UTC
GObject allows derived classes to add accessors for a property that base classes do not have. But vala is more strict that GObject. Gcr-3.gir:943.7-943.29: error: Type and/or accessors of overriding property `Gcr.CertificateRenderer.label' do not match overridden property `Gcr.Certificate.label': incompatible set accessor. I can't build a vapi because Gcr, because GcrCertificate.label is read-only and the derived class GcrCertificateRenderer.label is readwrite. You can see the code that does the check in GObject here: http://git.gnome.org/browse/glib/tree/gobject/gobject.c#n1402
Created attachment 226905 [details] [review] valaproperty: Don't be stricter than GObject in compatible prop checks GObject allows a derived property to be more accessible than the base class property. Make vala match this behavior so we can build vapis for libraries that do this.
This should be revisited.
*** Bug 783218 has been marked as a duplicate of this bug. ***
In general I'm not sure this is Vala specific, but any strongly typed language will enforce read only properties. This is a pattern that can be referred to as command query separation put forward by Bertrand Meyer with the Eiffel language. I think such strong typing would also apply to Rust, Ocaml, Haskell, D, Go and any other strongly typed language with GObject bindings. Personally I would not see this removed from Vala for Vala written interfaces. Maybe what Vala is doing differently is enforcing an interface file as well. In this case the interface given in the GObject Introspection Repository file. Given that the type system in C is optional then there are examples where a read only parameter becomes read/write when it is overridden. So I guess the pragmatic solution is for Vala not to type check the interface files and assume the external implementation is well designed. Fundamentally the decision is about the future direction of Vala. If Vala is purely a way of writing GObject C then the type checking is not important. Vala will just be an imitation of the C type system where there is a conflict. On the other hand if Vala/Genie are to be a way of writing robust native applications then I think Vala should enforce these rules, but it may be pragmatic to accept an external interface file can be allowed to break type checking in some instances.
(In reply to Al Thomas from comment #4) > Fundamentally the decision is about the future direction of Vala. I think in many ways it's a question of "Should GObject-based libraries work out of the box with Vala". Today, the reality is no. Personally, I think the answer to that should be yes, but it's not my project.
(In reply to Christian Hergert from comment #5) > (In reply to Al Thomas from comment #4) > > Fundamentally the decision is about the future direction of Vala. > > I think in many ways it's a question of "Should GObject-based libraries work > out of the box with Vala". Today, the reality is no. Personally, I think the > answer to that should be yes, but it's not my project. The assumption is that GObject bindings are there for inter-operability between languages. So are you saying the bindings you have problems with work fine in other strongly typed languages like Rust, Ocaml, Haskell, D and Go? I suggested two solutions: 1. Remove such type checks from all Vala code 2. Remove such type checks from externally generated interface files only However if the interface implementation also affects other strongly typed languages then it is a problem with the implementation of the interface not the user of the bindings. I know C allows that, but it defeats the purpose of inter-operability between languages if a binding can not be used by a set of languages. So the question "Should GObject-based libraries work out of the box with Vala"? The answer is of course yes. However, if other strongly typed languages don't work with that implementation, then the future of Vala will be that it is for writing GObject stuff at a higher level than C. Alternatively if Vala highlights a problem with an implementation first then it allows the implementation to be corrected before other strongly typed languages fail with it. As to ownership of the project, Vala is a community based project. So it is useful to get informed and insightful comments before implementing a solution. Any comments on how other strongly typed languages handle this would be helpful.
(In reply to Al Thomas from comment #6) > So the question "Should GObject-based libraries work out of the box with > Vala"? The answer is of course yes. However, if other strongly typed > languages don't work with that implementation, then the future of Vala will > be that it is for writing GObject stuff at a higher level than C. > Alternatively if Vala highlights a problem with an implementation first then > it allows the implementation to be corrected before other strongly typed > languages fail with it. This type of design is idiomatic GObject. So that is unlikely to change anytime soon unless someone writes static analysis tooling to warn people. What you can do from static bindings approach is to add accessor functions at the location where the type becomes variant. It at least allows libraries to continue being used. On particular difficult override would be the combination of G_PARAM_WRITABLE and G_PARAM_CONSTRUCT_ONLY. I suspect you'll need custom constructors in that case.
*** Bug 575439 has been marked as a duplicate of this bug. ***
-- 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/vala/issues/326.