2) added where I was not checking for JSVAL_NULL from brendan.
3) got rid of 'xpcom32' references.
4) added nsIEcho::ReturnInterface as a loopback for testing the above.
5) removed some redundant retval setting code.
- check static members of instances in JavaMembers.put
- do not unwrap Wrappers before calling NativeJavaMethod.findFunction
or NativeJavaObject.coerceType; both methods may need extra information
provided by the wrapper.
- separate Java signatures for resolving overloaded methods and script
signatures for error messages, so we can distinguish primitive types
from classes.
- separate Java signatures for resolving overloaded methods and script
signatures for error messages, so we can distinguish primitive types
from classes.
- prevent a NativeJavaClass from being treated as a wrapped instance of
java.lang.Class
- correct bug which preferred the *less* specific of two classes in
NativeJavaMethod.preferSignature
- add new LC3 conversion rules to NativeJavaObject.coerceTypes.
- coerce JS numbers to Java numbers or chars only if the JS number is in
range.
- JS_PushArguments{,VA} and JS_PopArguments to convert a list of C/C++ values
passed as actual arguments into an 'jsval *argv' on the JS stack.
- Clean up and robustify ConvertArgs test command in the js shell.
To wit:
Attached are a couple of small fixes for building in the js/ subdir.
These are for FreeBSD-CURRENT, and for building in a seperate OBJDIR.
The FreeBSD one is a quick and dirty. The real fix is pobably just to
use OS_LDFLAGS as defined by configure...
Re: netscape.javascript.JSObject ?
Date:
Thu, 03 Jun 1999 17:52:42 -0700
From:
Frank Mitchell <frankm@eng.Sun.COM>
Organization:
Java Products Engineering
To:
Norris Boyd <norris@netscape.com>
References:
1 , 2 , 3 , 4 , 5 , 6 , 7 , 8
Norris Boyd wrote:
>
> Sorry--missed the checkin of a new file. It's there now.
>
> I'd also added a small change for the "inheritance" of JavaScript array methods.
Actually, I've already done that (and for String as well). It still
fails some LC3 regression tests, though.
I'm including a tarfile that includes the previous changes and the new
ones.
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
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
