GNOME Bugzilla – Bug 590306
Kill of Abstract* for usage of virtual functions in interfaces
Last modified: 2009-09-07 09:31:31 UTC
Abstract* classes are needed in programming languages that does not support virtual functions in interfaces. As GObject supports them it would be better to move default implementations to interfaces as soon as vala supports them. It would have the benefits: - Making local changes. Currently adding new method to interface require adding it to interface and then overloading it in abstract class. - Not breaking API every time new method is added to interface. - Allowing default methods for classes which for some reson cannot inherit from Abstract*. - Removing number of files/classes etc. therefore minimising complexity.
Abstract classes are not bound to be sub-classed by all the implementers of the collection interfaces.
(In reply to comment #1) > Abstract classes are not bound to be sub-classed by all the implementers of the > collection interfaces. Yes - I'm fully understend it. However putting overloadable virtuals in interfaces (allowed by GObject but not Vala) have it's benefits: 1. DRY - There is no doubling of interface definitions both in Vala code and C generated structs. 2. It can be used by any class even if inheriting Abstract* is not possible 3. AFAIK Such pattern is already in use in GTK+. Usage of Abstract* is a simply copy of C# and Java where virtuals in interfaces are not allowed. 4. It allows adding methods, such as toArray, without breaking API (or even ABI if in-Vala padding is used). I know that it is not currently possible with Vala but I cannot see how it would harm when it will be possible. I can see however certain benefits. I would be therefore grateful for longer explanation of 'RESOLVED WONTFIX'.
Because these are interfaces. We need to keep the APIs clearly SEPARATED from the implementations. As I already told, all the implementers of the interfaces would not want to inherit the implementations provided in the Abstract* classes. For instance, in the future we may enhance AbstractList and split it in two base implementations to enable people to more easily implement sequential or random-access lists of their own. So we clearly can't put the implementations provided by AbstractList in the List interface. Your second point is not a valid point for a collection framework as there is no other responsibility you could give to a collection in addition to being a collection. I don't see why breaking the API during the development phase is a problem for your. The goal is that we have a stable 1.0 API that WON'T change. As such, having the possibility to add methods without breaking API is a non-sense for me. Finally GTK+ has lots of implementations details that spits out their APIs and that kind of practices are a bad example and clearly a no-go either for Vala or Gee. Sorry if I had not told that correctly in my first comment. I personally appreciate a lot all your contributions as lots of stuff would not currently be in Gee without you. However, I would like that we keep Libgee evolving in a sane way which this proposal is not at all. This won't be "fixed".
(In reply to comment #3) > Because these are interfaces. We need to keep the APIs clearly SEPARATED from > the implementations. As I already told, all the implementers of the interfaces > would not want to inherit the implementations provided in the Abstract* > classes. > > For instance, in the future we may enhance AbstractList and split it in two > base implementations to enable people to more easily implement sequential or > random-access lists of their own. So we clearly can't put the implementations > provided by AbstractList in the List interface. > Well - I belive you point is partially valid. For example while formally to_array is part of API but nearly all collection will have the same. To get the idea I will recall the Haskell classes (which are not the same as in OOP). For example for Arrow class you need to implement only arr and first methods as rest of them may be easily defined in terms of them. However you may redefine them. > I don't see why breaking the API during the development phase is a problem for > your. The goal is that we have a stable 1.0 API that WON'T change. As such, > having the possibility to add methods without breaking API is a non-sense for > me. > Well. We might want to add in version 1.2. Or 1.4 etc. Yes - GLib/GTK+ does have certain faults in API (GtkTreeModel for example) but one of big advantages is stable API (which is an advantage even in FLOSS). Of course - untill 1.0 API may change freerly. > I would like that we keep Libgee evolving in a > sane way which this proposal is not at all. This won't be "fixed". I guess that goal of other people on bugzilla. We just have different views on what 'sane' is. I belive that my current status is 'accept but disagree'.