Re: [Kawa-commonlisp-dev] Java representation of define-class slots

[Per Bothner]

On 06/22/2013 01:37 PM, Per Bothner wrote:
> On 06/22/2013 01:09 PM, John Cowan wrote:
> > #|kawa:1|# (define-class foo () (x1) (x2))
> > #|kawa:2|# (define-class bar () (y1) (y2))
> > #|kawa:3|# (define-class foobar (foo bar) (z1) (z2))
> > /dev/stdin:3:22: invalid super type
> > /dev/stdin:3:27: invalid super type
> > #|kawa:4|#
> >
> > Replacing the empty superclass list with (<object>) doesn't help.
> > What's that about?
>
> This bug (which I haven't dug into) unless happens with line-at-a-time
> evaluation.  If you wrap all 3 define-classes in a begin, or put them
> in a file (and evaluate without the -f flag) then it works.

I checked in a fix for this.  I also checked in a testcase
derived from you bug report (testsuite/defclass2.scm).

The problem when compiling foobar is that the imported foo and
bar *fields* in the previously-compiled "module classes" did not
have the 'final' flag set.  That meant the variable weren't
treated as constants, which meant they weren't
resolved to the actual "class values".

The tricky part was figuring out the cleanest way to fix
this.  I preferred to have the fields be 'final', because
that is more logical and precise.  More importantly, it's
what happens in non-immediate mode, and it always preferable
to minimize difference between immediate mode and non-immediate
mode - while still being efficient.

The reason that the field was made non-final, was so it could
be initialized using reflection using Compilation#setupLiterals.
So I had to decide on the best way around that.  I cleaned up
and fixed a few small related issues.
--
        --Per Bothner
address@hidden   http://per.bothner.com/