This is the mail archive of the kawa@sourceware.cygnus.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Kawa Servlets


"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/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]