Re: Kawa Servlets

[Per Bothner <per at bothner dot com>]

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

> My logic seems to run as follows:
> 
> 1) We need CLOS.

No, I don't think we "need" CLOS.  It would be very nice to
support something CLOS-style, preferably compatible with Guile's GOOPS.

> 2) We need at least the option for single dispatch CLOS class/method
> groups to map to a Java class.

I'm not sure we do.  We do need some way to express this in Kawa.
It is not clear that CLOS syntax makes that much sense, since it
would be quite restricted/stylized CLOS, plus you need some flag
or syntax to tell Kawa to dispatch using Java virtual methods.
I can see such a feature having some use:  Easier to port some
CLOS-like code; more familiar for some people.

> In this case we are willing to accept
> some hacks and ugliness to make it happen. e.g. restriction that methods
> must be in same source file. Or whatever hack is necessary.

I think it would be better to have full CLOS-like dispatch plus
a more Java-like define-class syntax (with methods declared in the class).
Having CLOS syntax but Java semantics has some use, but I'm not
sure how much.

> 3) If we have (2) then auto-generated CLOS style interface seems
> straight-forward. Just generate a CLOS class

Why? Kawa/CLOS classes would be translated to a mix of Java
classes and interfaces.  If you already have a Java class,
no point in generating a CLOS class, and then translating
it to a Java class.

> and appropriate generic functions.

Well, there are some questions here.  For example, how do you
*name* the generic functions?  Just the name of the Java method?
I suspect a prefix plus the Java method may make more sense.
What if there are multiple method with the same name but different
type signatures?  Should these become one generic function or multiple?
I think it has to be a single combined generic functions, but then
how do you dispatch?  First dispatch on the non-this parameter types,
and then do a virtual function call matches Java semantics best (plus
you have the advantage that you can do the first part at compile time),
but it is different from CLOS.

> Since CLOS is more of a super set I would think [mapping Java to CLOS]
> makes at least as much sense.

The complication I was thinking of is how you define the generic functions.

> Partly because "invoke" itself is rather annoying.

Well, Scheme has other keywords (like let, let*, define) that are
not in Java.  They are arguably also annoying.  Removing may be
an interesting project - but the result is no longer Scheme.

> Partly because to use
> many Java classes requires inheriting from them. E.g. to write a Servlet
> you have to inherit from "Servlet". Is this actually possible in Kawa
> right now?

You can use the (object ...) form to inherit, basically producing an
anonymous class.

There is a a new define-class form, but it isn't documented, as it
isn't really useable yet.  Soon, I hope.

It might be worth adding special cmpiler support for servlets, like I
recently did for applets.  (If you compile with --applet, then the
"main" class inherits from Applet.  We might do something similar
with --servlet - though I prefer a more generalizable solution.

> In an ideal world I think there is a CLOS system. Java classes are CLOS
> objects with single dispatch.

In my model, we have various kinds of Types.  Java classes as well as
CLOS clases are instances of a Type.  Each Type is implemented using
a Java type (class, interface, array, or primitive).  A CLOS class
is implemented using a Java interface.  Types can be
created as run-time (thus providing parameterized types).

>  You can define your own objects with
> multi-dispatch. If you inherit a Java class with a new CLOS object it
> works in the obvious way.

I don't know what you mean by this.

> Like I was saying, I'd like to be able to just say....
> 
> (define-class MyServlet (Servlet)
> ...)

Yup.  That's (partially) implemented.

> (define-method doGet (MyServlet)
> ...)

That one is trickier, but I do plan on implementing something like it.
It probably won't be the preferred way of writing servlets.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/