This is the mail archive of the
kawa@sourceware.cygnus.com
mailing list for the Kawa project.
Re: Kawa Servlets
- To: "Nic Ferrier" <nferrier at tapsellferrier dot co dot uk>
- Subject: Re: Kawa Servlets
- From: Per Bothner <per at bothner dot com>
- Date: 10 Mar 2000 13:25:45 -0800
- Cc: kawa at sourceware dot cygnus dot com
- References: <s8c8fa52.007@tapsellferrier.co.uk>
"Nic Ferrier" <nferrier@tapsellferrier.co.uk> writes:
> The methods doGet, doPost and so on would be mapped to whatever
> Scheme file it was mapping to by simply calling eval(). This allows a
> certain level of mangling of the servlet engine internals.
Well, I don't want to encourage use of eval.
Better, I think to require or load some Scheme-compiled class.
> For example there should be one Scheme environment per
> servlet-context.
That makes sense.
> I agree it would be nice to be able to have total control over the
> resulting class from scheme compilation, including what package forms
> compile to and any class they will extend.
We already have the former; the latter would be trivial to add,
since I already did the hard work when implementing --applet.
> But it's kinda hard before the module system is in place. Once the
> module sysyem is in place it would be good to have an argument (when
> you declare a module) to indicate what package the resulting class
> will belong to and any class it extends.
There are two possible ways to specify these: On the Kawa command
line, or in the Kawa source file. Ideally, we should support both.
Since a module is a source-file (or rather vice versa: a source file
compield to a module), the way to specify package names and
super-classes is with some top-leval declaration.
> Of course that raises great difficulty in terms of syntax errors
> because a sub class must declare constructors of the right type and so
> forth. Perhaps we can accept the restriction of you only extend
> classes that have no-arg constructors.
Yes, I would do no-arg constructors first. We could handle
constructors perhaps with a `define-constructor' declaration.
I plan to provide would be two "styles" for declaring classes when using
Scheme: (I have been thinking about a non-Scheme-like syntax for Kawa,
where I would probably combine these two forms.)
* The module syntax, which uses key-words like `define' to
declare fields and methods. A Scheme source file implicitly
defines a class, but we may also add an explicit `module'
keyword to allow nested module-style class definitions.
* The `object' and `define-class' forms, where the `define'
keywords are implied by the syntax. These can be nested
nside other "bodies".
For the module-style syntax, what do people think of the following?
(module-name <CLASSNAME>)
Causes the enclosing module to be compiled to the class named
CLASSNAME. If CLASSNAME does not contain a period, it is prefix by
the default package name specified by the -P flag. If no module-name
declaration is specified, the default is given by the -P flag combined
with the source file name (without a file type extension).
(module-extends <CLASS>)
Causes the enclosing module to extend the specified class.
(module-implements <INTERFACE> ...)
Causes the enclosing module to implement the specified interfaces.
These are not the tersest syntax I can imagine, but they are simple
to implement, to understand, and unlikely to conflict with future
syntax.
As an example:
(module-name <p.foo>)
(module-extends <javax.servlet.http.HttpServlet>)
(define (doGet (req :: <javax.servlet.http.HttpServletRequest)
(res :: <javax.servlet.http.HttpServletResponse))
#!void
...)
Better would be:
(define (doGet (req res)
...)
I.e. have Kawa be smart enough to default the parameter and return types
by seeing in the super-clas or -interfaces define a method with the
give name and number of parameters.
I also think it makes sense to have a special servlet class
that has a one-argument doGet method, that returns a "result value";
the value of that result is then sent as the response.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/