Re: module extension

[Per Bothner <per at bothner dot com>]

mgd@swarm.org (Marcus G. Daniels) writes:

> I'd be happy with that, simply because this is a blocker for me.  ;-)
> But it looks like "<" and ">" get mangled, and that this construct
> doesn't result in a new constructor (instead it is "$LsInit$Gr()").

Well, you can of course put in whatever kludge you like.  I don't
think I will put in any hack like (define (<init>) (super 1)), because
I don't much care for it, and there are other Kawa things I need to
work on first.  My concern is that the module-as-class feature is very
nice, but I don't want to bend it too much to support Java class
idiosyncracies.  A module i primarily a module, and its design needs
to support that of modules first.  That means mutually recursive
modules should be allowed.  That means the "body" of a module cannot
be an instance initializer (because instance allocation cannot be
separated from instance initialization in Java).  Instead the body
must be some kind of separate "run" method.  But allowing the
programmer to specify separate independent init and run actions
is tricky, and I'm not sure it's a good idea.

One possibility that makes sense is to provide an option such that
top-level actions in a module are executed in an <init> method
instead of a 'run' method.  This option would preclude mutually
recursive modules, but would be useful for your needs.  Then you would
not need special syntax to define a constructor - instead anything
you put in the top-level is part of the class's constructor.
This still would not support defining a non-default constructor,
nor call the super-class's constructor, so there probably isn't
all that much point in it. 

Any class that can be serialized will need a default constructor, and
its a good idea to make one in any case.  In that case, you don't need
to be able to call define or call an initializer explicitly.  Just use
default initializer, and initialize what needs to be initialized in
the body of the module.

Admittedly, this isn't really a great answer for Kawa/Java integration.
My concern is that Kawa will have *three* syntaxes for defining classes
(at least):
(1) using the module facility;
(2) using the 'object' special form;
(3) using the planned 'define-class special form.

The 'object' form does support object initialization, since a field
initializer will be compiled into a constructor.  We would still
need a way to call the super-class initializer, but I think that
is reasonable to add.

The 'define-class' special form will by default handle CLOS-style
multiple inheritance, implemented using interfaces, but will also
support options to use standard Java single inheritance, and also
other features such as constructors.  That is partly why I'm loath to
put too much effort into coming up with a kludge for constructors
using the module facility, when those kind of features would make more
sense in the 'define-class' facility.

This is not my final word on the subject.  If you're willing to do
the implementation, I'm willing to try to specify some syntax that
is as unobjectionable as I can ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/