This is the mail archive of the
kawa@sourceware.cygnus.com
mailing list for the Kawa project.
Re: Possible bug with compilation/stdout?
- To: balaban ittai <ittaib at cs dot bgu dot ac dot il>
- Subject: Re: Possible bug with compilation/stdout?
- From: Per Bothner <per at bothner dot com>
- Date: 11 Apr 2000 10:31:45 -0700
- Cc: Kawa Mailing List <kawa at sourceware dot cygnus dot com>
- References: <Pine.SGI.3.95-heb-2.07.1000411152602.135238A-100000@claret>
balaban ittai <ittaib@cs.bgu.ac.il> writes:
> Now I'm a bit confused. From what I understand, you can compile a module
> as an "instance" module (which is the only type implemented now). This is
> fine with me.
> So how does a line like `(new SchemeTest()).theMainMethod();' not fit in
> with this scheme?
It does, partly. However, the "top-level actions" are performed by
a "run" method, so you need to do:
SchemeTest st = new SchemeTest();
st.run();
st.theMainMethod();
(which causes the the-main-method to be called twice).
There are various reasons that Kawa uses a "run" method:
* It seems cleaner to separate out the top-level actions, and not
have them be run by the constuctors. This is similar to how Thread works.
* It makes it easier to handle circular imports if you do it in two
phases (constructor+run). The idea is that an import (require) is
called inside the "run" method *after* the current module has been
created and registered. So if the required module ends up requiring
the current module, it finds it immediately.
> 1) I haven't been able to use the `this' syntax. Whenever I use (this),
> anywhere in my code, the compiler crashes with an internal error
> (NullPointerException).
The implementation of (this) is a bit of a kludge. I haven't had time
to make it robust. The applet example in the manual works (at least
it did when I tried it). I recommend you use (this) inside a function,
but not inside any tested scopes.
> 2) Compiling files into packages: If I have (module-name ...) in the
> module source, where ... is 'foo.SchemeTest or "foo.SchemeTest" or
> <foo.SchemeTest>, the module always gets compiled as a toplevel (not
> inside package foo) class. The only way this works is using the
> -T foo.SchemeTest command line option. Note that even using
> -P foo. -T SchemeTest doesn't work.
Indeed, there is a bug. I'm working on it.
By the way: I'm glad you're trying this stuff out. This is the first
feedback I've gotten on the new module facilities!
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/