This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: cannot derive from module class: new feature request
- From: Per Bothner <per at bothner dot com>
- To: wowa1 at online dot ru
- Cc: kawa at sources dot redhat dot com
- Date: Mon, 21 Apr 2003 23:34:12 -0700
- Subject: Re: cannot derive from module class: new feature request
- References: <3E9934C2.3020005@online.ru>
Vladimir Tsichevski wrote:
I'm trying to use modules as Java classes, so among other things
I want to derive module classes module from module classes.
The problem is that kawa module classes implicitly declare a set of
apply... methods, and some of them are final.
Redefining final methods is illegal in Java.
My feature request is as follows:
1. As a minimum: make all module methods non-final. It takes to correct
two lines of code only.
I'm not opposed, but I wonder why you care, especially, given the
following request. Why do you care about overriding the apply
methods, when you don't want them anyway?
2. As a maximum: provide one more module declaration to disable creation
of all stuff required for using
the compiled class as module. The class resulted may be used as any
other Java class, similar to classes
created with define-simple-class, but with more control over methods
visibility and scope. Moreover, no more
extra class is required to keep static stuff when using
define-simple-class.
I'd rather improve define-simple-class. For fields we already have the
mechanism with the 'option-keyword: option-value' syntax, and there
are some options already existing in Stk, Guile, or Common Lisp we
should just implement. For methods, we could add support for options.
For example:
((methodName arg-list)
allocation: 'class access: 'protected :: <return-type>
body)
--
--Per Bothner
per at bothner dot com http://per.bothner.com/