It knows the difference between a function definition (a statement)
and a function expression (where it is returning the function as a
value), and it leaves the names off the expression case.
It seems that this is a common error javascript compiler/interpreter
writers make: they see the name on the function and do the wrong
thing when a function expression has a name. Safari 2 and IE both
choke on this. Now you have discovered swf9 does too.
We should file a bug with Adobe.
On 2008-01-11, at 12:17 EST, Henry Minsky wrote:
How does it know to leave the names on if it is a top level global
function
declaration?
On Jan 11, 2008 11:34 AM, P T Withington <[EMAIL PROTECTED]> wrote:
Did you try enabling the debugSimple flag? That should cause the
script
compiler to drop the names from functions in the back end so you
would not
have to change the tag compiler.
On Jan 11, 2008, at 10:23, "Henry Minsky" <[EMAIL PROTECTED]>
wrote:
Background for others on the list: we found that the swf9 runtime
gets an
error when we create named functions and assign them
to slots, such as is done for debugging purposes. It seems to cause
a bug
in their JIT such that the function can be called once,
and then generates a VM verify error the second time it is called.
For example , an onclick handler might compile to
{ $m1: function foo_$m1 () {this.parent.animate('rotation', 360,
1500,
true)}}
But the swf9 runtime apparently gets confused that this function is
named, yet is being
assigned to some other var and invoked dynamically.
I noticed that in the tag compiler, the code that generates setter
functions for attributes is always assigning a name to
the function
In NodeModel.java addAttributeElement there is code which compiles
the
"setter" attribute of an <attribute> tag
if (setter != null) {
String srcloc =
CompilerUtils.sourceLocationDirective(element, true);
// Maybe we need a new type for "function"?
String setterfn =
srcloc + "function " +
parent_name + "_" + name + "_onset" +
" (" + name + ") {" +
"\n#pragma 'withThis'\n" +
srcloc + setter + "\n}";
if (setters.get(name) != null) {
env.warn(
"a setter for attribute named '"+name+
"' is already defined on "+getMessageName(),
element);
}
setters.put(name, setterfn);
}
It looks like this is always making a named function. I think we had
better conditionalize that, and maybe
it actually causes bugs in some DHTML runtimes? Would this be a
test that
would tickle the bug for DHTML?
<class name="foo">
<attribute name="bar" setter="this.baz = bar + ' is the value of
bar'"/>
</class>
<foo>
<handler name="oninit">
this.setAttribute('bar', 259);
Debug.write('baz = ', this.baz);
</handler>
</foo>
--
Henry Minsky
Software Architect
<[EMAIL PROTECTED]>[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
