Re: Asynchronous i/o, Garbage Collection, Funtion Instance references
Richard Maher,
I really appreciate you taking the time to answer my questions. I shall
derive what benefit I may from your elucidation. I can see I shall need
to study ASTs.
I think for this reply, I'm going to respond by topic rather than
respond to particular quotes.
(1) Polling
You wrote: "The simple fact is I don't want polling! That is why I am
asking about establishing ASTs in a JavaScript."
Perhaps polling could still be useful in making its own opposite,
serving as a kind of internal glue hidden from the interface. However,
since you hate it enough to call it "anathema", then by all means, don't
do it. TIMTOWDI.
(2) Why not...?
Why not rock gardens and giant electromagnetic relays powered by
hamsters? :)
I was just curious. I'm not bothered by the combination. Mmmmhm... I
was recently intrigued by the charming combining of Ruby, Java, and
Processing that is Ruby-Processing. I mean to try messing with it.
(2) Associating data with functions
I would probably just create an object by hand, assign whatever
properties to it, and then assign the function in question to it. Call
the function on the object, and then the function can obtain the
contextual parameters using the "this" keyword. Use constructors if
desired. But yeah, closures too, if one wants.
(3) Stringifying functions
I was doing more research on eval(), when I ran across something not
entirely relevant but interesting nonetheless. Functions can be
converted "back" to function declaration strings. According to EMCA 262:
"An implementation-dependent representation of the function is returned.
This representation has the syntax of a FunctionDeclaration. Note in
particular that the use and placement of white space, line terminators,
and semicolons within the representation string is
implementation-dependent." (15.3.4.2)
In my tests of my IE 6 and FF 3 browsers, I found it doesn't keep track
of changes to variables, etc., after declaration, nor does it capture
any of the containing context of closures. Still, I think it's neat,
and a serialization of a function declaration if not a function with all
its actual state.
(4) Eval() and dynamic functions.
Eval can create pretty dynamically varied functions, not just static ones.
a = {
name : "func",
id : 0,
create : function() {
eval("" + this.name + this.id + "= function () { alert(\"" +
this.id + "\"); }" );
this.id++;
}
};
a.create();
a.create();
func0();
func1();
func0();
(5) Array Efficiency
I would have to run experiments. I couldn't say how to do it.
(6) Pointer, Identifier
I think an array index is a close enough approximation of a pointer
value, or if assign the function object to some named property, there
you have your identifier. Sorry I can't offer anything better.
(7) Functions and wrapping
I think I can explain why "Object jsFunc" in the second post gave you
more mileage.
Functions are objects in Javascript, which should cause them normally to
be wrapped in JSObject (EMCA section 13 & "Working with Wrappers" in the
Mozilla Liveconnect Overview). Trying to treat them as type Object in
the parameter list still results in them wrapped in JSObject. However,
if you try to treat them as String objects, then you get the result of
the original javascript object's toString(), which is not the function
object (Mozilla LC "Javascript to Java Conversions: Other Javascript
Objects").
Jon.