kawa-commonlisp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Kawa-commonlisp-dev] [PATCH] Type refactoring.


From: Jamison Hope
Subject: Re: [Kawa-commonlisp-dev] [PATCH] Type refactoring.
Date: Fri, 21 Sep 2012 16:32:56 -0400

Hi Charles,

On Sep 21, 2012, at 2:49 PM, Charles Turner <address@hidden> wrote:

> Hi all,
> 
> On 20 August 2012 21:10, Charles Turner <address@hidden> wrote:
>> I decided to change my approach a little, and since the patch is
>> getting quite large, I thought it best to pause and get a check up.
> 
> So I took no response to mean it was OK :-)

Yeah, sorry about that. The day job was keeping me pretty busy for
a while with low-level C and robots, which was making it hard to
find time for the mental context switch to Kawa.

But in the meantime I also got a new laptop for work and so I'm
back to Java hacking for a bit as I attempt to get all the usual
software packages installed again. Kawa compiled without issue
under Oracle's JDK 7u7, but some other packages have some hard-coded
paths to the old Apple Java directories or other catching up to do
for Mountain Lion.

> -- I've gone ahead and
> done the rest of the type refactoring, find attached. I couldn't see a
> decent compromise between small overlapping patches and this
> monolithic patch. To much interdependence.

Looks pretty good to me for the most part. A few comments:

1. The only change to kawa/lang/Translator.java is to remove a
   javadoc comment on checkDefaultBinding() which states
   "The default implementation does nothing." But the implementation
   of that method is still <code>{ return null; }</code>, so the
   comment still seems to apply. I recommend taking Translator.java
   out of the diff.

2. It looks like the only changes to Language#getLangTypeFor(Type)
   are indentation? Let's keep that as a separate change, too.
   At some point when Per's got some free time (haha) maybe we can push
   through a few untabify/indent patches to make Kawa source whitespace
   more consistent.

3. I'm not a huge fan of how CommonLisp's booleanType is instantiated
   in both getTypeFor(Class) and getNamedType(String). It seems like
   one of those methods should just defer to the other. Perhaps this
   would work (haven't actually tried it):

@Override
public Type getTypeFor (Class clas)
{
  if (clas.isPrimitive())
  {
    return getNamedType(clas.getName());
  }
  return Type.make(clas);
}

-Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com






reply via email to

[Prev in Thread] Current Thread [Next in Thread]