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 669541 - Allow sealed/final classes
Allow sealed/final classes
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: general
0.41.x
Other Linux
: Normal enhancement
: 1.0
Assigned To: Vala maintainers
Vala maintainers
: 720159 (view as bug list)
Depends on:
Blocks: 689924 724347 768225
 
 
Reported: 2012-02-07 08:14 UTC by Tristan Brindle
Modified: 2018-05-22 14:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tristan Brindle 2012-02-07 08:14:25 UTC
Both C# and Java allow the programmer to specify classes which cannot be used as a base class. This allows for some optimisation as the compiler knows how virtual functions will be resolved, and so it can avoid a virtual function call in some cases. C# uses the keyword 'sealed' for this (so I suppose Vala should too), whereas Java uses 'final'.

GObject also has a concept of sealed classes, although not explicitly. If the instance and class structures are defined in the .c file rather than the .h file then it's not possible to inherit from the classes in C. This is the case for GBinding, for example, which cannot be used as a base class (although Vala has no way of representing this).

In the GObject world, using a sealed class like this also has the advantage that private members can be placed in the instance struct rather than in a separate 'priv' struct. This avoids a second pointer dereference when accessing private members, which can be a valuable micro-optimisation in very very tight loops.
Comment 1 Evan Nemerson 2013-12-10 02:42:50 UTC
We need to support this for bindings at least.  It is apparently not uncommon to keep *Class structs private in order to make a class private at the C level, which GIO does for GSimpleAction (see bug #720159), among others.  Hopefully it's possible to figure out from the GIR whether or not a class should be final.

People also try to subclass stuff in glib (GString, GHashTable, etc.), which can cause unpleasant things to happen.  A final keyword (or an annotation) would let us catch this in valac instead of waiting for the CC to emit an error.
Comment 2 Allison Karlitskaya (desrt) 2013-12-11 03:44:34 UTC
*** Bug 720159 has been marked as a duplicate of this bug. ***
Comment 3 Ondřej Tůma 2016-06-30 06:46:34 UTC
As i wrote here https://mail.gnome.org/archives/vala-list/2016-June/msg00079.html Python GObject could inherit from "final" classes:

from gi.repository.Gio import Menu


class AppMenu(Menu):
    def __init__(self):
        super(AppMenu, self).__init__()
        sec = Menu()
        sec.append("New document", "app.new-window")
        sec.append("Open document", "win.open-document")
        self.append_section(None, sec)
        sec = Menu()
        sec.append("Save document", "win.save-document")
        sec.append("Save document as", "win.save-document-as")
        self.append_section(None, sec)
        sec = Menu()
        sec.append("About", "app.about")
        self.append_section(None, sec)
        sec = Menu()
        sec.append("Close document", "win.close-window")
        sec.append("Quit", "app.quit")
        self.append_section(None, sec)


May be, there could be official declare from GLib/GTK+ developers, if it's classes need to be "final" or not. Another song is if Vala need final classes.
Comment 4 GNOME Infrastructure Team 2018-05-22 14:20:21 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/vala/issues/278.