Re: Rhino LiveConnect: need help?
Date:
Wed, 02 Jun 1999 19:33:37 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Scott Furman <fur@netscape.com>, Norris Boyd <norris@netscape.com>
CC:
mallen@eng.Sun.COM
References:
1 , 2 , 3 , 4
Scott Furman wrote:
> In order to bring Rhino LiveConnect support up to the level of the
> C-engine, the features of LiveConnect version 2 and version 3 would
> need to be added. You can see some details of LC2 and LC3 features
> here. I would guess that 80% of the time would be spent implementing
> one feature: LC3's new method overload resolution scheme.
OK, I think I have something that implements the new overloaded method
resolution scheme ... I'm still working on getting the regression tests
running smoothly, but from command-line testing it seems to work. It's
not the *cleanest* code I've ever done, though: in particular, it has
too many static methods and type-checking code for my tastes. (Hey,
should we spin the type coercion and comparison stuff to some other
module entirely? Right now it's mostly in JavaNativeObject, with the
preference stuff in JavaNativeMethod.) I'm also not sure why some of
this stuff is public, and whether there might be backward-compatibility
problems with what I've done, particularly in repurposing the
COMPARISON_* constants.
Would you guys be kind enough to review this for me? I'm hoping to
check it in once I get an ID, but it wouldn't hurt to have another pair
of eyes or three (pairs, I mean). I've attached a tar/gzip of the
source files I've changed (or added), plus a diff.
Thanks,
Frank
Re: Rhino LiveConnect: need help?
Date:
Wed, 02 Jun 1999 19:33:37 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Scott Furman <fur@netscape.com>, Norris Boyd <norris@netscape.com>
CC:
mallen@eng.Sun.COM
References:
1 , 2 , 3 , 4
Scott Furman wrote:
> In order to bring Rhino LiveConnect support up to the level of the
> C-engine, the features of LiveConnect version 2 and version 3 would
> need to be added. You can see some details of LC2 and LC3 features
> here. I would guess that 80% of the time would be spent implementing
> one feature: LC3's new method overload resolution scheme.
OK, I think I have something that implements the new overloaded method
resolution scheme ... I'm still working on getting the regression tests
running smoothly, but from command-line testing it seems to work. It's
not the *cleanest* code I've ever done, though: in particular, it has
too many static methods and type-checking code for my tastes. (Hey,
should we spin the type coercion and comparison stuff to some other
module entirely? Right now it's mostly in JavaNativeObject, with the
preference stuff in JavaNativeMethod.) I'm also not sure why some of
this stuff is public, and whether there might be backward-compatibility
problems with what I've done, particularly in repurposing the
COMPARISON_* constants.
Would you guys be kind enough to review this for me? I'm hoping to
check it in once I get an ID, but it wouldn't hurt to have another pair
of eyes or three (pairs, I mean). I've attached a tar/gzip of the
source files I've changed (or added), plus a diff.
Thanks,
Frank
private/primpl.h, and md/*.h) to mozilla/dist. NSPR files will get
these headers from the source tree, via -I$(MOD_DEPTH)/pr/include and
-I$(MOD_DEPTH)/pr/include/private. Non-NSPR files must not include
these private NSPR headers and should get the exported NSPR headers
from mozilla/dist/<platform.OBJ>/include.
warren%netscape.com
hangas%netscape.com
erik%netscape.com
ducarroz%netscape.com
mscott%netscape.com
slamm%netscape.com
mang%subcarrier.org
norris%netscape.com
sspitzer%netscape.com
rogerl%netscape.com
dougt%netscape.com
pinkerton%netscape.com
rickg%netscape.com
wtc%netscape.com
putterman%netscape.com
mcmullen%netscape.com
akkana%netscape.com
sfraser%netscape.com
briano%netscape.com
chuang%netscape.com
alecf%netscape.com