Re: [Vala] Final / Sealed classes in Vala

[Phil Housley <undeconstructed gmail com>]

2009/9/26 Michael B. Trausch <mbt zest trausch us>:
> The idea of a sealed/final class can be used to mean a few things:
...
>        --- Mike

I agree with everything Mike said there, so no need to repeat it, I
just want to add a real example.  I work a lot with a Java web
framework called Wicket (wicket.apache.org), which has a very
expressive and very OO API.  The default position you take when
writing an application is not "does this class have the options I
want" but "that class does something like what I want, I'll extend
it".

This makes writing applications very intuitive, as you use the
framework exactly like any other Java code.  You don't just have some
library calls you can make, you have instead every class open for you
to mess around with.

The cost is that you could fairly easily destabilise your application
by failing to follow the same design rules as the wicket developers,
and who wants to learn how to hack the framework, just to be able to
use it?

The solution is that Wicket has final modifiers on anything where
behaviour is crucial for consistency, and also on some semi-crucial
things where there are no known uses for extension.  Two examples,
more or less accurate but it is the weekend, so no promises:

1) Every component has an id.  This must never change during the
lifecycle of the component.  As such, the getId() method is final, so
that no component can break the rules.  This is a case when a
non-virtual method could theoretically be used if that was possible,
although that would add extra restrictions on future framework
development of course.

2) All form components have a standard processing cycle for input
conversion/validation etc.  It is a design requirement that this cycle
is always the same for any form component, so the process method is
final in all usuable (non-abstract) form component classes.  On the
other hand, if you really wanted you could implement a new component
that had a different cycle, by starting from a lower level base class.
 You would then override the process method, and create a new
component that acted like a form component in some ways but,
importantly, did not follow the contract guaranteed among all real
form components.

The aim of all this is that you can do pretty much anything you want,
except things that can (almost) only lead to trouble.

-- 
Phil Housley