Re: Asynchronous i/o, Garbage Collection, Funtion Instance references
Richard Maher wrote:
As suggested in previous reply. Just send a string with the
function name and use eval in the response processing JS.
Do you mean when Jon said this: -
Does this mean you trying to send Javascript functions over the network?
Why? Couldn't you just use some kind of identifier for the function,
and just have both sides aware of the function already? Or send pure
data instead of functions? I have visions of you using eval() and
storing the function declarations as strings. I bet someone in the
comp.lang.javascript group will find the mere mention horrible.
Yep.
Were you suggesting storing and eval-ing the "function declarations" also,
or quoting something else about passing the "function name"?
If you have the function code on the page you only need to send
the name.
Anyway, not that anyone's a huge fan of eval() and regardless of that why in
this case would you opt for calling a JavaScript function that executes an
eval(functionParam) as opposed to a Java
JSObject.eval(StringAfterRoundTrip)? A bit "better" where at least some of
the value-added function verbs/declarations and data are in the main HTML/JS
file? Pre-parsed? Only half pregnant :-) Never used JSObject .eval() but I'm
guessing that it does what JS.eval() does? (Never used JavaScript.eval()
either.)
You could call it from the Applet as well, but I would rather do the
JS stuff in JS instead of in Java.
Also, what am I gaining by imposing an eval() requirement in Function X that
couldn't be functionally achieved by just manipulating its parameters. IOW,
for a specific application it maybe useful for its JS function to
eval(param3) but for others function parameters 3 and 4 being strings and 5
the string representation of an int could suffice.
The method name as a parameter is more flexible than an argument
to a fixed method with a gigantic switch.
JS->Java->JS or JS->Java->server->Java->JS should not matter.
Surley one requires (de)serialization and the other does not? This matters
heaps to me! My kingdom for a generic 32 (or event 64) bit pointer :-(
Serialization and deserialization of a string is not a problem.
1a) Pass whatever context info that is needed as a string and, on return,
eval() it inside a variable (name-selected) JavaScript function. (Or perhaps
JSObject.eval())
1b) Pass whatever context-info is needed as strings and, on return, massage
the "arguments" array to a variable (name-selected) function.
2) Maintain a JavaScript Array of references to function instances (or other
complex Objects), one entry for each message sent. Fed from the tail and
removed from the head.
3) (de)Serialize a mythical pointer to an anonymous function/closure, and
pray that the JavaScript GC won't zap it before my Java Applet calls it.
Before consigning "3" to the dust-bin, let me just say that I really, really
liked the idea a lot!
I like "1b" but if "1a" has real advantages then I'm happy to hear them.
"2" is more along the lines of what I was trying to achieve but having to
maintain that queue-like Array (especially if the Socket is to be shared
among pages on different tabs and/or browser instances) requires something
to link-up several receieved messages and check that they were meant for
element[0]. (I'll ask about the possibility of gaps later on an inter-tab
question. . .)
So 1, 2 or 3? (And if 1 do you prefer "a" or "b"?)
1a
Least code and in the spirit of a dynamic language.
Arne