Re: [Vala] Final / Sealed classes in Vala

[Arto Karppinen <arto karppinen mail suomi net>]

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
> 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.

And yet in Vala, and other languages that do not virtualize everything,
i would do it something like this:

GObject
 \---> 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
  explicitly forbidden.
- Vala newer allows someone to modify base class behaviour, unless
  explicitly allowed.

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
------------------------------
arto karppinen iki fi