[Rhino] importPackage() when not in Rhino shell?
Date:
Tue, 14 Nov 2000 09:37:39 -0000
From:
"Benjamin Geer" <geerb@midas-kapiti.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
The importPackage() and importClass() functions provided by the Rhino shell
seems as if they would be very generally useful. Unless I've missed
something, they don't seem to be available to scripts compiled using the
JavaScript compiler, or to scripts that are run using Script.exec(). Is
there any chance these functions could be made available for all scripts to
use? This would save a lot of typing; one could then always write a = new
Foo() instead of a = new Package.com.baz.bar.foo.Foo().
--Benjamin Geer
slobo@espial.com wrote:
>
> Hello Mike
>
> In the following test case, tester returns "undefined cat" in Rhino
> while in NN it returns "meow cat".
>
> Thanks
>
> Steven
>
> /////////////////////////////////////////////////////////////////////
> function tester(nest){
> var nest = nest+" cat";
> alert(nest);
> // nest now contains the value undefined.
> }
>
> tester("meow");
More changes to support non NativeJavaObject wrappers
Date:
Fri, 03 Nov 2000 17:56:38 +0100
From:
Igor Bukanov <igor@icesoft.no>
To:
nboyd@atg.com
Hi, Norris,
In post 1.5 rhino one can introduce own wrappers for arbitrary Java
objects. But I think to fully support this
org.mozilla.javascript.ScriptRuntime should be changes as well: its eq
and shallow_eq contain references to NativeJavaObject, this should be
replaced at least to Wrapper (see the atached patch). Even better
solution would be to add to WrapHandler methods to compare wrappers: I
can send a patch for that as well.
There is a small usability problem as well: if
org.mozilla.javascript.JavaMembers would be public I do not need to copy
it to a package with non NativeJavaObject.java wrapper.
Regards, Igor
56318 function literals with names don't work right
57045 negative integers as object properties: weird behavior
58479 functions defined within conditional phrases are always crea
[Rhino] Optimization for OptRuntime.thisGet
Date:
Mon, 23 Oct 2000 17:50:53 +0200
From:
Hannes Wallnoefer <hannes@helma.at>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I found a little oddity in
org.mozilla.javascript.optimizer.OptRuntime.thisGet().
get() is called twice on thisObj, once right at the beginning, and once
when starting to walk down the prototype chain. Below is what I think
this should look like - the prototype walk now begins with thisObj's
prototype, if it exists.
Also, (thisObj == null) was checked only after thisObj.get() was called,
so I moved that up in front.
Hannes
PS: I just made the changes in the news msg editor, so there may be
stupid mistakes.
updated Global, Main and ImporterTopLevel
Date:
Mon, 23 Oct 2000 14:37:45 +0100
From:
Matthias Radestock <matthias@lshift.net>
To:
nboyd@atg.com
Norris,
I've made some more changes to shell.Main and shell.Global in order to
reduce their mutual dependency, enable "quit" and get "load" to operate
in the local scope.
see attachments for updated .diffs.
Matthias.
