Re: [Vala] Final / Sealed classes in Vala

[Jan Hudec <bulb ucw cz>]

On Fri, Sep 25, 2009 at 16:22:41 +0200, Uwe Strempel wrote:
> > Does anyone have a concrete example of where this sort of thing is
> > actually appropriate, just for the sake of blocking sub-classing?
> I don't have useable example. Sealed or final methods or classes "can" be
> optimized just in time compiler.

Yes. Virtual methods can be dispatched non-virtually.

This makes difference in Java, where all methods are always virtual. That's
not the case of either C# nor Vala. And since virtual methods usually get
called via base class or interface where virtual dispatch is unavoidable,
sealing classes does not have any performance benefits there.

> I didn't see any useable example for sealed (.net) or final (java) classes.
> It's like the internal stuff in .Net on a so called "extensible" framework
> made by a big american company.

I don't know any examples where sealed is good. I some where it is evil.

There are many sealed classes in the .net framework. It's easily possible to
come up with loads of use-cases where your life would have been easier if
they were not.

As an example, I subclassed std::string in C++ project to guard against
somebody writing unlocalized strings by mistake. You had to call the
translation function or explicitly state the string does not need
translation. The same idea can be used to guard against unsanitized strings
in security-critical code or against unquoted strings in formatted output.

Now .NET System.String is sealed...

Note: In vala, you can subclass string, but since it's struct, available
features are somewhat limited. For the above use-case it is likely enough.

> By the way sealed doesn't protect you from overriding the class in C# 3.0
> and above.

.NET 4.0 documentation (on MSDN web) still claims sealed classes cannot be
inherited.

> I think sealed and final stuff modifiers for classes has no need in vala.
> But final like in java has also another meaning on properties or method
> parameters, which marks the object as unmodifieable.

In other words, it does the same with them as 'const' does in C/C++.

Personally I greatly miss const in C#. I would often want to give somebody an
object, but I don't want them to modify it. Doing that via interface is a lot
of extra work and incurs the virtual dispatch cost at runtime and const
solves that nicely.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>