This is the mail archive of the
kawa@sourceware.cygnus.com
mailing list for the Kawa project.
Re: Kawa Servlets
Per Bothner wrote:
>
> 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.
I say "need" in that to interact nicely in a Java system you need an
object system, and CLOS/GOOPS is as close to something standard as there
is.
> > 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.
Would it be restricted? Wouldn't it be possible to implement it by
having every generic function a part of the Java class that corresponds
to its first argument. So if we had..
(define-generic f ((x Bar) (y Baz))
..)
(define-generic f ((x Bar) (Y Foo))
..)
(define-generica f ((x Foo))
..)
would translate to..
class Bar {
f(Object y) {
if (y instanceof Baz) {
...
} else if (y instanceof Foo) {
...
}
}
class Foo {
f() {
...
}
}
> > 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.
More than one object system sounds like a bit of a problem to me.
> > 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.
Well, what I should really say is to have it appear as if a CLOS class
exists which is mapped to the Java class. So be able to interact with a
Java class as if it is a CLOS 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?
Yes.
> I suspect a prefix plus the Java method may make more sense.
Why? Is it in case there are two unrelated methods with the same
name? I can see this is a problem but it can probably be optimised in
the more usual case.
> What if there are multiple method with the same name but different
> type signatures? Should these become one generic function or multiple?
One.
> 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
I would have thought the other way. Dispatch on "this" first. Isn't that
more Java-ish and CLOS-ish and faster?
>(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.
The thing is "invoke" is not scheme. You don't write
(invoke string-append foo bar) for example.
> > 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.
Ok, I didn't notice this before. But is an anonymous class enough? I can
think of cases where you really want a named class. I'm not sure how
anonymous classes interact in Java.
> 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.
I just mean that it's desirable to inherit existing Java classes. Like
inheriting from HttpServlet.
>
> > 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.
Any reason why?