Entries tagged ‘javascript’

document.write('<scr'+'ipt defer src="//:" '
  + 'onreadystatechange="if(this.readyState==\'complete\'){dojo._loadInit();}">'
  + '</scr'+'ipt>'

function checkStyle() {
  dummy           = dom.create("div");
  dummy.className = CSS_DUMMY;
  dom.getBody().appendChild(dummy);
  pollStyle();
};

function pollStyle() {
  if(dom.getComputedStyle(dummy, 'marginLeft') == '42px') afterStyle();
  else setTimeout(pollStyle, 10);
};

function afterStyle() {
  if(dummy && dummy.parentNode) dummy.parentNode.removeChild(dummy);
  dummy = null;
  fire(null, true);
};

.sIFR-dummy { 
  width: 0px;
  height: 0px;
  margin-left: 42px;
  z-index: 0;
}

if(dojo.render.html.ie && dojo.render.os.win){
    document.attachEvent("onreadystatechange", function(e){
        if(document.readyState == "complete"){
            dj_load_init();
        }
    });
}

/*@cc_on @*/
/*@if (@_win32)
document.write("<script id=__ie_onload defer src=javascript:void(0)><\/script>");
var script = document.getElementById("__ie_onload");
script.onreadystatechange = function() {
  if (this.readyState == "complete") {
    init(); // call the onload handler
  }
};
/*@end @*/

(function nonAnonymousMethod() { 
  var aProperty;
}).aProperty = null;

JavaScript runs in a single thread, which is why a lot of things, including XHR, work with callbacks. But sometimes, sometimes you need to escape the thread [1] and run you code in a new one. One example is event based code, where your stuff should not run while the event is still being propagated. The easiest way to accomplish this is by using setTimeout():

setTimeout(myCode, 0);

Since JavaScript is single-threaded, and the timeout 0 milliseconds, the timer will fire when there is no JavaScript being executed. In theory it’s still possible for other threads to be started, blocking the timer, but this shouldn’t lead to any practical problems.

Happy coding!

[1]: For sake of argument. Technically it’s all the same thread, and execution would depend on queues and callstacks, but I find it easier to think of this as in different threads.

Here’s something that came up at Jot last week. Which event will be fired continuously, if you hold down a key: onkeydown or onkeypress?

The answer is that it depends on both platform and browser. In general, Windows-based browsers fire only onkeydown, except for Firefox/Win which also fires onkeypress. On the Mac and on Linux, only onkeypress is fired, and onkeydown is not fired on the Firefox browser for these platforms. Something to keep in mind when you bind the “iterate over items while holding arrow up or down key” behaviour to your application. See the testcase.

var qtFlash = false; // Is QuickTime rendering Flash?
var flashPlugin = navigator.plugins['Shockwave Flash'];
for(var i = 0; i < navigator.mimeTypes.length; i++) {
    var mime = navigator.mimeTypes[i];
    if(mime.type == 'application/x-shockwave-flash' 
    && mime.enabledPlugin != flashPlugin) {
        qtFlash = true;
        break;
    }
}

var qtFlash = false; // Is QuickTime rendering Flash?
var flashVersion = 7; // Stub for real detection code
for(var i = 0; i < navigator.mimeTypes.length; i++) {
    var mime = navigator.mimeTypes[i];
    if(mime.type == 'application/x-shockwave-flash' 
    && !new RegExp('.*Shockwave\\sFlash\\s' + flashVersion
    + '.*').exec(mime.enabledPlugin.description)) {
        qtFlash = true;
        break;
    }
}

if(this.ieWin) {
  try {
    this.flashVersion = parseFloat(
                new ActiveXObject('ShockwaveFlash.ShockwaveFlash.7')
                .GetVariable('$version').match(/([\d,?]+)/)[1].replace(/,/g, '.')
            );
  } catch(e) {}
}

The most powerful thing about the JavaScript programming language are it’s scoping rules. In programming languages, scope is what makes the world go round. It defines the context in which the code executes. The context contains objects which are available to the code. To draw a real-world analogy: Say you’re in your living room, and you want to watch some television. You can, because the television is in your living room. But what if you’re in the kitchen?

Scopes can be chained to each other. This means that if some portion of the code is not available in the current scope, you’ll be able to find it somewhere else. If you’re in the kitchen, and it is chained to the living room via a door (as in my place), you can simply walk to the living room to watch television.

In JavaScript there is a variable scope chain. All objects are stored inside variables (and in JavaScript everything is an object). New scopes can only be created when you define a new function. The newly created scope will be chained to the scope it was created in. And for good measure there is a global scope, available right from the start. In most JavaScript implementations (read: browsers), this is the window object.

As I said, in JavaScript everything is an object. You could view the scope as an object as well: the variables you use are simply properties on this object. Normally you can’t access this scope object, it is implied by the language and everything is handled by the interpreter. There is, however, one exception to this rule. The window object acts as a public scope object. Let’s have a look:

var foo = 'bar';
window.baz = 'thud';
alert(window.foo); // alerts 'bar'
alert(baz); // alerts 'thud'

As you can see the foo variable is accessible by window.foo, just as the window.baz property is accessible by baz.

So how do we find the variables on the scope chain? First the JavaScript interpreter checks if the variable has been declared in the current scope (or: if the property exists on the hidden scope object). If not, it’ll check the chained scope. This process continues until the variable has been found, or until the window object has been reached and the variable hasn’t been declared even on that object. In this latter case an exception will be thrown.

This process makes it possible to use the same variable name in different scopes, effectively masking the other variables. There is one caveat in JavaScript though: unless you declare the variable with the var keyword it will be created in global scope.

By now it’s time for some examples:

var foo = 'bar'; // variable declared in global scope
function a() { // creates a new scope, chained to the global scope
    alert(foo);
}
a(); // alerts 'bar'

function b() { // creates a new scope, chained to the global scope
    foo = 'the quick brown fox'; // in which scope does the `foo` variable exist?
}
alert(foo); // alerts 'bar'
b();
alert(foo); // alerts 'the quick brown fox'

function c() {
    var foo = 'thud';
    alert(foo);
}
alert(foo); // alerts 'the quick brown fox'
c(); // alerts 'thud'
alert(foo); // still alerts 'the quick brown fox'

Of course we can chain more than two scopes together:

function d() { // what scope is this function chained to?
    var foo = 'thud';

    function e() { // creates a new scope, chained to the scope of `d()`
        alert(foo);
    }

    e();
}
d(); // alerts 'thud'

Function e() has access to the scope of function d(). This is called a closure. As I said this is one of the most powerful things of JavaScript. This lets you do some really cool things. Ever wanted to create private methods in JavaScript? Now you can!

function A() {
    function hidden() {
        alert("I'm a private method!");
    }

    this.visible() {
        alert("I'm a public method. I can also invoke `hidden()`.");
        hidden();
    }
}
var a = new A;
a.visible();

Up to you to figure out why this works.

This also lets us create Singleton objects:

var b = new function() {
    this.hello = function() {
        alert('Hello world!');
    }
}
b.hello();

Or functions which have private methods in their scope:

var c = (function() {
    function hidden() {
        alert("I'm a private method!");
    }

    return function() {
        alert("I'm a public method. I can also invoke `hidden()`.");
        hidden();
    }
})();
c();

This latter technique is referred to as Block Scope.

One thing to watch out for with these techniques are memory leaks. You can find more info about those by reading my Event Cache article. In any case, let that not be a discouragement! Closures are cool. Use them.

public static void foo (String bar) {
  // do things
}

public static void foo (String[] bar) {
  // do things
}

function say (value) {
   value = value || "";

   if (typeof (value) != "string") {
      if (value.constructor == Array)
         value = value.join("\n");
      else {
         var result = "";
         for(var prop in value)
            result += prop + ": " + value[prop] + "\n";
         return result;
      }
   }

   alert(value);
}

case
when 1 + 1 == 2
  puts "1 + 1 is indeed  2"
when 1 * 1 == 1
  puts "1 * 1 is indeed 1"
else
  puts "Somebody must have disproved mathematics"
end

function say (value) {
   value = value || "";

   alert (Function.$case (
      typeof value == "string", // when
         value, // expression

      value.constructor == Array, // when
         function () { // expression
            return value.join("\n");
         },

      function () { // else
         var result = "";
         for(var prop in value)
            result += prop + ": " + value[prop] + "\n";
         return result;
      }
   ));
}

Function.$case = function () {
   var condition;
   for (var i = 0, expr = null; i < arguments.length; i+=2, expr = null) {
      condition = arguments[i];
      if (i == arguments.length - 1)
         expr = condition;
      else if (condition === true)
         expr = arguments[i + 1];
      else if (typeof (condition) == "function" && condition () === true)
         expr = arguments[i + 1];

      if (typeof (expr) == "function")
         return expr ();
      else if (expr != null) // To obviate the need for superfluous functions, you can also use a value instead of a function
         return expr;
   }
}

Peter-Paul Koch recently launched the adddEvent() recoding contest. Of course, I couldn’t say no to such a challenge, so here’s my article explaining my entry. You might want to write the short terminology overview I wrote a while back before diving into this article.

First off, let’s look at the requirements for the event code:

• must work in all modern major browsers: Mozilla, Opera, Safari and Internet Explorer.
• must follow DOM standards (which also means adding the same listener only once)
• must not leak memory
• must respect the this keyword (scoping must work correctly)

Then there are some niceties we might want:

• allowing you to set the scope
• providing a way to modify the event object

With that in mind, I started writing. After three iterations of simplifying, I came to the current solution. Let’s look through it piece by piece.

Oh blimey, that looks like code!

var __DomEvents__ = new function()

I’m creating the necessary functions inside __DomEvents__. I’m using the underscores because the actual addEvent() and removeEvent() functions are exported into the window object and I want a nice little namespace of my own. Also note the new function() part: the methods for the script are defined in an anonymous class, which is immediately instantiated. JavaScript’s solution for Singletons.

var registry = {};

function registryKey(id, type, fn)
{
  return id + "#" + type + "#" + fn;
}

function isInRegistry(key)
{
  return registry[key] != null;
}

This is the code which keeps track of all event listeners. registry is a hash table in which the listeners are stored. registryKey() takes care of creating a unique key to store the listener with. It does this by combining the ID of the event target, the event type, and the string representation of the listener. Finally isInRegistry() is a utility method we can use to see if a key has already been registered.

function invoke(key, evt)
{
   if(!isInRegistry(key))
      return null;

   _evt = __DomEvents__.alterEventObject(evt);
   // If the alteration method returned an object, use that as the event
   // object.
   if(typeof _evt == "object")
      evt = _evt;

   var handler = registry[key];
   var scope = handler.scope;

   // Evade Function#apply()
   scope.__DomEvents_listener__ = handler.listener;
   scope.__DomEvents_listener__(evt);
   scope.__DomEvents_listener__ = null;
}

invoke() will make sure the listener is invoked in the right scope. First — of course — it makes sure the listener is still in the registry. It then calls alterEventObject(), which allows us to modify the event object before it’s sent to the listeners. And at last it’ll invoke the listener!

The next part is a bit tricky. We first load the handler, a small object stored in the registry which contains a reference to the listener and the scope. Then it sets a property, __DomEvents_listener__ (now if that isn’t unique, what else is???), which references the listener. This means that when the listener is invoked via the property its scope will be scope. That’s exactly what we want so we invoke the listener via the property and then set the property back to null. We ain’t leaving no traces, are we now?

var targetIdCount = 0;

function targetId(target)
{
   if(target == document)
      return "__DomEvents_ID_document";
   if(target == window)
      return "__DomEvents_ID_window";

   var id = target.getAttribute("id") || target.uniqueID;

   if(id == null){
      id = "__DomEvents_ID_" + targetIdCount++;
      target.setAttribute("id", id);
   }

   return id;
}

Remember how registryKey() uses the ID of the event target? We need a way to find this ID. For the document and window objects, we’ll use a static ID, for HTML elements we’ll try to derive the ID from the element. Our first attempt is the id attribute. If it doesn’t exist we check for uniqueID. The latter is a property in Internet Explorer which contains a unique id (you didn’t expect that, did you?) which you can use to reference the element (through document.getElementById()). If we still don’t have an ID, we’ll have to set it ourselves. IDs generated by this code are prefixed with __DomEvents_ID_. targetIdCount is used to make sure we assign unique IDs — with each assignment the count is updated. And finally we return the ID.

window.addEvent = function(target, type, listener, scope)
{
   var key = registryKey(targetId(target), type, listener);
   scope = scope || target;

   //    Check if the listener hasn't been registered already.
   if(isInRegistry(key))
      return false;

   // Hey, it's a new listener!
   handler = {
      listener:   listener,
      scope:      scope,
      invoker:    function(evt)
                  {
                     invoke(key, evt);
                  }
   }

   registry[key] = handler;

   if(target.addEventListener){
      target.addEventListener(type, handler.invoker, false);
   } else if(target.attachEvent){
      target.attachEvent("on" + type, handler.invoker);
   } else {
     return false;
   }

   // Reset variables:
   target = listener = scope = null;

   return true;
}

Yes! That’s the code you’ve been waiting for, right? Let’s go through this step by step. First we create the key for this listener. We also check if it’s already been registered. Since isInRegistry() takes a key as parameter, listeners are distinguished by their function, not the scope. Talking about which, the line scope = scope || target; means that the scope will be scope, unless it hasn’t been specified, in which case it’ll be target (and the this keyword refers to the event target the listener was added to, great!).

You can also see how the handler object is created. The invoker property holds the method which will be added as the DOM event listener — it’s just a wrapper for the listener you specify. The handler object is added to the registry and the invoker method is added as the event listener.

There are some key things in this code with regards to memory leaks. By storing the listener and scope in an object separate from the event target,
we can prevent circular references between the target and the listener and the target. And even though the invoker method is a closure, by setting the values of target, listener and scope to null we make sure IE won’t be taking a leak.

By now we are almost finished with the code. We only have to look at a way to remove the listeners:

window.removeEvent = function(target, type, listener, scope)
{
   var key = registryKey(targetId(target), type, listener);

   if(!isInRegistry(key))
      return false;

   var invoker = registry[key].invoker;

   registry[key] = null;

   if(target.removeEventListener){
      target.removeEventListener(type, invoker, false);
   } else if(target.detachEvent) {
      target.detachEvent("on" + type, invoker);
   } else {
      return false;
   }

   return true;
}

Actually I think you are perfectly capable of understanding this method. Onwards to the final cleaning up:

this.alterEventObject = function(){};

The alterEventObject() method is a dummy method for invoke(). Note how it’s set as __DomEvents__.alterEventObject().

Documentation for the public methods

addEvent()

Adds the listener.

Parameters:

• target: the element to which the listener will be added. document and window are supported as well.

• string >> type: the type of the event, without the “on” prefix.

• function >> listener: the listener you want to add.

• object >> scope: the scope this listener should be invoked in. Default: el.

  Returns:

• boolean: whether the listener has successfully been added or not.

removeEvent()

Removes the listener.

Parameters:

• target: the element to which the listener will be added. document and window are supported as well.

• string >> type: the type of the event, without the “on” prefix.

• function >> listener: the listener you want to remove.

• [object >> scope]: the scope this listener should be invoked in. Default: el.

  Returns:

• boolean: whether the listener has successfully been removed or not.

alterEventObject()

A function which can alter the event object. Override this to use your own.

Parameters:

• evt: Event object to alter.

  Returns:

• [object]: the modified event object. You can also modify evt directly.

And… that’s it!

Wow, I just explained the entire code! You can see the required example page and also the source (littered with custom-style documentation, that’ll have to be extracted in the near future). Like most of my other work the code is licensed under the CC-GNU LGPL.

Also I’d like to thank Michaël van Ouwerkerk for testing the script on Windows, and Lief van der Baan for checking the article for spelling and grammar mistakes. Thanks guys!

I hope you enjoyed the article. If you have any questions, you are welcome to contact me.

Finally, here’s a short follow-up to the original Event Cache article. Let’s start with the best news: the script is now known to work in Internet Explorer, Safari and Mozilla.

Implementing

Something which had to be read through the lines in the original article was how to actually implement the script. Therefore, a little tutorial.

First we take Scott Andrew LePera’s addEvent code. The addEvent function [1] is as follows:

function addEvent(obj, evType, fn, useCapture){
    if (obj.addEventListener){
        obj.addEventListener(evType, fn, useCapture);
        return true;
    } else if (obj.attachEvent){
        var r = obj.attachEvent("on"+evType, fn);
        return r;
    } else {
        return false;
    }
}

This doesn’t take care of IE/Mac and other legacy browsers, so you might want to use this method by Simon Willison to get around that.

Anyway, onwards with adding the event to the cache! Here’s the modified version of Scott Andrew’s code which does exactly that:

function addEvent(obj, evType, fn, useCapture){
    var result;
    if (obj.addEventListener){
        obj.addEventListener(evType, fn, useCapture);
        result = true;
    } else if (obj.attachEvent){
        var r = obj.attachEvent("on"+evType, fn);
        result = r;
    } else {
        return false;
    }

    EventCache.add(obj, evType, fn, useCapture);
    return result;
}

We also need to register the onunload handler so we can flush the cache:

addEvent(window, "unload", EventCache.flush);

And that’s it!

Sam Schillace pointed out that the code above was wrong… the method would return before Event Cache kicked in. Big Oops! Thanks for pointing that out, Sam!

(Edited June 3, 2005).

Event Cache, but without the cache

Ramon Leon pointed out to me the other day that it’d be easier to add an unload event which removes the event handler for each event, instead of caching the event and setting an unload event to flush the cache.

Well, yeah, that approach sounds good to me. It doesn’t mean, however, that you’re no longer using a cache: the unload event still contains references to the characteristics of the original event, you just can’t access those references. It’s a minor difference though, I’d say choose which method suits your needs best.

Mark, I’ve got a challenge for you! Try to make some JavaScript that emulates the behavior of the :target psuedo-class in IE.

No, I’m not trying to be rude, this would honestly be something very cool, and to be honest (still), my JavaScript skills are not that good.

That’s the challenge I recieved this morning from The Wolf (not The Real Wolf though). Well, I thought it was doable, so I accepted:

That should be possible… challenge accepted!

And indeed, after about 30 minutes of hacking it’s done: Emulate the CSS :target Pseudo-Class in IE. The demo only works in Internet Explorer, you can view source there to see the code.

I hope you can use it!

Oh, one more thing:

Great to hear it! If you can do it, everyone owes you a beer or something…

You all owe me one!

Via Jeffry Zeldman’s alter ego Apartness’ blog come the following practices from Tanya Rabourn regarding web standards (emphasize mine):

In order to anticipate future browser compatibility we require conformance to the following W3C standards:

HTML

Validate to either the W3C’s XHTML 1.0 transitional or strict doctype http://www.w3.org/TR/xhtml1/

CSS

Validate to the W3C’s CSS 2.1 or 1.0 http://www.w3.org/TR/CSS21/ http://www.w3.org/TR/CSS1

Javascript

Javascript will never use browser detect but instead object detection to test for browser support of properties, arrays and methods

I think we all know that things aren’t black and white, just how it is in this case. Object detection surely is a good idea: if you want to fetch an element which has a certain ID, you need document.getElementById, so you might as well want to make sure that method is supported before you run your script. Unfortunately browsers have other bugs than “simply” not supporting DOM methods.

Take Safari, for instance. It won’t repaint the document if you append a new node to it. To work around this you need to use a hack which adds an empty string to the innerHTML of the node you just appended to. Quite obviously you don’t want to use this hack in other browsers: you need to use browser detection to determine if the hack is necessary. And to add to the confusion: this bug has been solved in Safari 1.3, so you might as well want to make sure not to use this hack in that browser.

By the way, did I mention innerHTML is not supposed to work in XHTML documents? You need to find a way to detect that as well…

To conclude: it’s a good idea to use object detection, but sometimes it just won’t cut it. And you don’t want to leave out awesome scripts because it uses browser detection, do you?

Yup, Jeremy Keith is completely right when he says that :hover is behavioural. That’s why I’m going to explain here how you should do :hover via the DOM. That’s right… I’m going to tell you!

Okay, so first we grab all the links on the page. We’ll do this on onload. I’m actually going to cheat a bit with the events, but I hope you’ll forgive me:

window.onload = function(){
    var links = document.getElementsByTagName("a");
    for(var i = 0; i < links.length; i++){
        links[i].onmouseover = function(){
            this.className += "hover"; // sorry, no support for multiple classNames here
        };

        links[i].onmouseout = function(){
            this.className = this.className.replace(/\bhover\b/, "");
        };
    };
    links = null; // look how I evaded memory leaks here!
};

And the CSS:

a.hover {
    text-decoration: none;
    font-weight: bold;
}

Ahhh.. that’s so much better. Now we have seperated style and behaviour completely. Time for some well deserved rest now.

You didn’t think I was serious about this, did you?

function(msg){ alert(msg); }("hello world");

function foo(msg){ alert(msg); };
foo("hello world");

var foo = function(msg){ alert(msg); };
foo("hello world");

function foo(){
    var msg = "hello world";
    alert(msg);
};

foo();

var msg = "hello world";

function foo(){
    alert(msg);
};

foo();

function foo(){
    var msg = "hello world";
    function bar(){
        alert(msg);
    };
    bar();
};

foo();

Event Cache is a small script which can store the events you have set on a page and remove them on unload. This way it can prevent memory leakage. Please read DHTML leaks like a sieve by Joel Webber for more information. Also, here’s a quote Jim Ley, who explains:

The Internet Explorer web browser [...] has a fault in its garbage collection system that prevents it from garbage collecting ECMAScript and some host objects if those host objects form part of a “circular” reference. The host objects in question are any DOM Nodes (including the document object and its descendants) and ActiveX objects. If a circular reference is formed including one or more of them, then none of the objects involved will be freed until the browser is closed down, and the memory that they consume will be unavailable to the system until that happens.

So, how can we solve this? If we make sure no references are left when the page unloads, there won’t be a problem. In the comments of Joel Webber’s article Dylan Schiemann mentioned that Alex Russell of NetWindows had written a solution for this problem. So I dived into the NetWindows code to look for it.

It turns out that what the NetWindows code does is caching all events set for the affected browsers and detaching the events on unload. Based on this principle I wrote EventCache.

Please also read the follow-up article.

Usage

The idea is that you hook EventCache into your normal event code. You simply add the information you need to set the event to the EventCache using the add method.

EventCache has the following properties and methods:

listEvents

An array whose items are arrays which contain the information in the following order: node, sEventName, fHandler, bCapture. See add for more information.

add(node, sEventName, fHandler, bCapture)

Add new information to listEvents.

node

A reference to the node on which the event has been set.

sEventName

The name of the event.

Please note: this name must not be prefixed with on for any browser but Internet Explorer. The actual event you use must be prefixed with on. For example, if your event is onclick, sEventName must be click. If you use a custom event you can’t use foo, but you have to use onfoo. Of course sEventName must be foo.

fHandler

A reference to the function which handles the event.

bCapture

A boolean which determines whether the event is triggered in capture mode or not. Does not apply to Internet Explorer.

flush()

Remove all cached events.

Please note: You have to make sure that EventCache.flush is fired on unload!

Examples

I’ve made two testcases. One with memory leaking, and one which uses Event Cache. You can also try the Event Cache testcase with feedback

As you can see these examples don’t use browser detection to see if cleaning the references is really necessary. That’s something for your own implementation.

Other Methods

There are some other ways to solve this problem. One would be to never keep references at all, but closures are too handy to do this. Another solution is to iterate over all elements in a document and remove specific events. This is the solution that Aaron Boodman proposed.

The downside with this method though is that it only works for events which use the so-called DOM 0 event model: element.onclick = function(){};. If you use element.attachEvent() or element.addEventListener() you need to remember the specific values you used to set the event, which means you have to cache it.

Considerations

The cache keeps references to the element on which you’ve set an event and the event handler. This means that it consumes memory itself. It also takes time to remove the events on unload.

Download and Licensing

EventCache is released under the CC-GNU LGPL. You can download version 1.0.

And Finally

If you have any questions about this article or the code, please contact me.

function foo(one, two, three, four, five){
    // do something
};

// let's call foo() with only the first and last argument
foo("hello", null, null, null, "world");

named({
    name : value,
    name : value
})

foo(named({one : "hello", five : "world"}));

foo("the", "ocean", named({three : "breathes", five : "salty"}));

sIFR.replaceElement("h1", "./vandenkeere.swf", named({sColor : "#000", sCase : "upper"}));

if(typeof sIFR == "function"){
    var template = named({sFlashSrc : "./vandenkeere.swf", sColor : "#000", sCase : "upper"});
    sIFR.replaceElement("h1", template);
    sIFR.replaceElement("h2", template);
};

named.Arguments = function named_Arguments(oArgs){

named.Arguments = function(oArgs){

00524       // Lookup for keyword failed, means this is an identifier
00525       // Apply anonymous-function hack below (eat the identifier)
00526       if (eatNextIdentifier) {
00527         eatNextIdentifier = false;
00528 #ifdef KJS_VERBOSE
00529         UString debugstr(buffer16, pos16); fprintf(stderr,"Anonymous function hack: eating identifier %s\n",debugstr.ascii());
00530 #endif

named.Arguments.prototype.constructor = named.Arguments;