Re: [Vala] Final / Sealed classes in Vala
- From: Arto Karppinen <arto karppinen mail suomi net>
- To: Phil Housley <undeconstructed gmail com>
- Cc: vala-list gnome org
- Subject: Re: [Vala] Final / Sealed classes in Vala
- Date: Sun, 27 Sep 2009 12:38:03 +0300
Phil Housley wrote:
2009/9/26 Michael B. Trausch <mbt zest trausch us>:
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
The aim of all this is that you can do pretty much anything you want,
except things that can (almost) only lead to trouble.
And yet in Vala, and other languages that do not virtualize everything,
i would do it something like this:
\---> WicketBase ( getId )
\---> WicketForm ( form validation )
\---> .. user inherits something ...
Now because WicketBase and WicketForm do not virtualize their functions,
and because the framework does not know anything about the
user inherited classes, there is no possibility that the user inherited
classes would affect base class or framework behaviour.
I think Java and Vala have fundamentally different virtualization models:
- Java always allows someone to modify base class behavious, unless
- Vala newer allows someone to modify base class behaviour, unless
In Java you need a keywork to forbid virtualization.
In Vala you need a keywork to allow virtualization.
For those examples to apply to Vala, you would first have to explicitly
allow something to be virtualized, and then explicitly forbid that
virtualization, which would to me sound more like a design failure in
the framework rather something that Vala should support.
arto karppinen iki fi
] [Thread Prev