Arto Karppinen wrote:
I still think that these kind of problems can be avoided in Vala code by
carefully selecting what and when to virtualize.
Once again to take the example of Gee. We needed to provide default
behaviour for add_all, remove_all, retain_all, ... methods, but wanted
concrete
On Tue, 2009-09-22 at 06:40 +0200, Marco Trevisan (Treviño) wrote:
Is it possible to define both in VAPIs and in a vala code a class which
can not be extended?
I mean something like final does for Java and sealed for C#...
It's planned to introduce `sealed' in a future version on both, the
On Sat, Sep 26, 2009 at 17:27:45 +0200, Didier 'Ptitjes' wrote:
Michael B. Trausch wrote:
The idea of a sealed/final class can be used to mean a few things:
...
To follow Phil with use cases, Libgee would be in great need for
final classes and methods.
As an example, we would like that
Phil Housley wrote:
2009/9/26 Michael B. Trausch m...@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
Arto Karppinen wrote:
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.
Then
2009/9/26 Michael B. Trausch m...@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
On Fri, 2009-09-25 at 20:52 +0200, Jan Hudec wrote:
But in the end it comes down to language design and in
vala's case, enforcing compile time errors instead of deferring
critical
errors and misbehavior at runtime. (just like abstract classes are
not
instantiatable, even if they don't
Hello,
Something I don't get here... The whole point of subclassing, is to
make something old, do something new.
Yes.
Isn't that like calling any developer that might be looking at
extending your class, an idiot? I'd have thought making sure virtuals
aren't miss-overridden, is the
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
On Wed, 2009-09-23 at 19:01 +0200, Frederik wrote:
Didier 'Ptitjes' wrote:
I think the problem to not have it in Vala is more a technical problem
where nothing will avoid C users (in the current GObject) to subclass
the classes that would be marked as sealed in Vala.
Vala already has
2009/9/22 Jan Hudec b...@ucw.cz:
On Tue, Sep 22, 2009 at 06:40:10 +0200, Marco Trevisan (Treviño) wrote:
Is it possible to define both in VAPIs and in a vala code a class which
can not be extended?
I mean something like final does for Java and sealed for C#...
I don't think so. Though some
Jan Hudec wrote:
On Tue, Sep 22, 2009 at 06:40:10 +0200, Marco Trevisan (Treviño) wrote:
Is it possible to define both in VAPIs and in a vala code a class which
can not be extended?
Yes. It is Java-specific idiom. In Vala, you just use namespace with
non-member functions.
Thanks, I'm very
Is it possible to define both in VAPIs and in a vala code a class which
can not be extended?
I mean something like final does for Java and sealed for C#...
I think they could be useful for grouping static methods in virtual
classes (I mean in a class which name has not a reference in a C
On Tue, Sep 22, 2009 at 06:40:10 +0200, Marco Trevisan (Treviño) wrote:
Is it possible to define both in VAPIs and in a vala code a class which
can not be extended?
I mean something like final does for Java and sealed for C#...
I don't think so. Though some classes are not inheritable
14 matches
Mail list logo
