Re: Kawa Servlets

[Chris <chris at bitmead dot com>]

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?