bind, apply, and call trap

quick one out of ECMAScript ml

var
    // used to trap function calls via bind
    invoke = Function.call,
    // normal use cases
    bind = invoke.bind(invoke.bind),
    apply = bind(invoke, invoke.apply),
    call = bind(invoke, invoke)
;

What Is It

This is a way to trap native functions method in a handy way. Used in a private scope, it can address these methods once so that we can rely nobody can possibly change them out there for some script injection and only if we are sure the script has been loaded at the very beginning.

How To Use Them

Here few examples:

// secure hasOwnProperty
var hasOwnProperty = bind(invoke, {}.hasOwnProperty);
// later on
hasOwnProperty({key:1}, "key"); // true
hasOwnProperty({}, "key");  // false

// direct slice
var slice = bind(invoke, [].slice);
slice([1,2,3], 1); // 2,3
slice(arguments); // array

// direct call
call([].slice, [1,2,3], 1); // 2,3
// direct apply
apply([].slice, [1,2,3], [1]); // 2,3

// bound method
var o = {name:"WebReflection"};
o.getName = bind(
    // the generic method
    function () {
        return this.name;
    },
    // the object
    o
);
o.getName(); // WebReflection

That's pretty much it, except if we don't trust native Function.prototype, we should not trust anything else as well so maybe it's good to use these shortcuts just because they are handy ;)

About JavaScript apply arguments limit

Just a quick one from ECMAScript ml ... it is true that browsers may have a limited number of arguments per function. This may be actually a problem, specially when we use apply to invoke a generic function that accepts arbitrary number of arguments.

String.fromCharCode

This is a classic example that could fail with truly big collection of char codes and here my suggestion to avoid such limit:

var fromCharCode = (function ($fromCharCode, MAX_LENGTH) {
    // (C) WebReflection - DO THE FUCK YOU WANT LICENSE
    return function fromCharCode(code) {
        typeof code == "number" && (code = [code]);
        for (var
            result = [],
            i = 0,
            length = code.length;
            i < length; i += MAX_LENGTH
        ) {
            result.push($fromCharCode.apply(null, code.slice(i, i + MAX_LENGTH)));
        }
        return result.join("");
    };
}(String.fromCharCode, 2048));

// example
alert(fromCharCode(80)); // P
alert(fromCharCode([80, 81, 82, 83, 84])); // PQRST

The revisited version accepts directly an array and performs the call ceil(codes.length / MAX_LENGTH) times.
Performances impact will be irrelevant while bigger Arrays will be parsed, hopefully, without problems.
If we still have problems we should never forget that userAgents may have a limited amount of available RAM so ... split the task or the operation or stream it.

As Summary

It's not that difficult to apply same concept with whatever function may suffer the apply and number of arguments limits: just define a maximum amount of arguments, in this case 2048, so that the task will be distributed without problems.

arguments, callee, call, and apply performances

We have dozens of best practices to improve performances. We also have common practices to accomplish daily tasks. This post is about the most used JavaScript ArrayLike Object, aka arguments, and its performances impact over basic tasks.

Why arguments

While it's natural for JavaScripters to use such "magic" variable, as arguments is, in many other languages everybody knows it does not come for free and it is rarely used.

<?php
function myFunc() {
    // function call for each execution
    // rarely seen in good PHP scripts
    $arguments = func_get_args();
}
?>

One clear advantage in PHP, Python, and many others, is the possibility to define a default value for each argument.

<?php

class UserManager extends MyDAL {
    public function exists($user='unknown', $pass='') {
        return $this->fetch('SELECT 1 FROM table WHERE user=? AND pass=?', $user, $pass);
    }
}
?>

This approach may brings automatically developers to code as if arguments does not exist. It's not an important value, everything has a default ... so, why bother?

Why callee

Specially because of black sheep Internet Explorer and its inconsistent/bugged (it does not exist, imho) concept of named function expression, our laziness frequently bring us to use this "shortcut" to refer the current executed function.

// the classic case ..
setTimeout(function
/*
  if named, IE will pollute the current scope
  with chose name rather than let it "be" only
  inside the function body, as is for every other browser
*/
() {
    // do stuff
    setTimeout(arguments.callee, 1000);
}, 1000);

Even if we are in a closure so that no risk will occur if we name the callback, we are still lazy and we don't even think about something like:

setTimeout(function $_fn1() {
    // do stuff
    setTimeout($_fn1, 1000);
}, 1000);

return function $_fn2() {
    // if stuff $_fn2() again;
};

Of course, how many $_fn1, $_fn2, $_fn3 we can possibly have in the current scope?
Somebody could even think about silly solutions such:

Function.prototype.withCallee = (function ($) {
    // WebReflection Silly Ideas - Mit Style
    var toString = $.prototype.toString;
    return function withCallee() {
        return $("var callee=" + toString.call(this) + ";return callee")();
    };
})(Function);

// runtime factorial
alert(function(n){
    return n * (1 < n ? callee(--n) : 1);
}.withCallee()(5)); // 120

// other example
setTimeout(function () {
    // bit slower creation ... but
    // much faster execution for each successive call
    if (animationStuff) {
        setTimeout(callee, 15);
    }
}.withCallee(), 15);

OK, agreed that 2 functions rather than one for each function that would like to use callee could require a bit more memory consumption ... but hey, we are talking about performances, right?

Why call and apply

Well, call and apply are one of the best JavaScript part ever. Everything can be injected into another scope, referenced via this, and while Python, as example, has a clear self as first argument, we, as JavaScripters, don't even think about such solution: we've got call and apply, who needs to optimize a this?
Well, somehow this always remind us that we are dealing with an instance, an object, rather than a primitive or whatever value sent as argument.
This means that even where it is possible to avoid it, we feel cooler using such mechanism:

function A(){};
A.prototype = (function () {
    // our private closure to have private methods
    function _doStuff() {
        this.stuff = "done";
    }
    return {
        constructor:A,
        doStuff:function () {
            _doStuff.call(this);

            // it could have been a simple
            _doStuff(this);
            // if _doStuff was accepting a self argument
        }
    };
})();

Furthermore, apply is able to combine both worlds, via lazy arguments discovery, and context injection ... how cool it is ...

The Benchmark

Since we have all these approaches to solve our daily tasks, and since these cannot come for free, I have decided to create a truly simple bench, hopefully compatible with a wide range of browsers. There is nothing there, except lots of executions, defined by times parameter in the query string, and a simple table to compare runtime these results.

Interesting Results

The scenario is apparently totally inconsistent across all major browsers, and this is my personal summary, you can deduct your one as well:

• in IE call and apply are up to 1.5X slower while as soon as arguments is discovered, we have up to 4X performances gap. There is no consistent difference if we discover callee, since it seems to be attached directly into arguments object.
• in Chrome call is slower than apply only if there are no arguments sent, otherwise call is 4X faster than apply and, apparently, even faster than a direct call. arguments costs generally up to 2.5X while once discovered, callee seems to come for free giving sometimes similar direct call results.
• in Firefox things are completely different again. Direct call, as call and apply, do not differ that much but as soon as we try to discover arguments.callee, for one of the first browser that got named function expression right, the execution speed is up to 9X slower.
• Opera seems to be the most linear one. Direct call is faster than call, and call is faster than callee. To discover arguments we slow down up to 2X while callee does not mean much more.
• In Safari we have again a linear increment, but callee costs more than Opera and others, surely not that much as is for Firefox

Summarized Results

A direct call is faster, cross browser speaking, and specially for those shared functions without arguments, we could avoid usage of call or apply, a self reference as argument is more than enough.
arguments object should be forbidden, if we talk about extreme performances optimizations. This is the only real constant in the whole bench, as soon as it is present, it
slows down every single function call and most of the time
consistently.

HINTS about arguments

To understand if an argument has not been sent, we can always use this check ignoring JSLint warnings about it:

function A(a, b, c) {
    if (c == null) {
        // c can be ONLY undefined OR null
    }
}

If we compare whatever value with == null, rather than === null, we can be sure this value is null or undefined.
Since generally speaking undefined is not an interesting value and null is used instead, also because undefined is a variable and it costs to compare something against it and it could be redefined as well while null cannot, it does not make sense at all to do tedious checks like this:

function A(a, b, c) {
    // JSLint way ...
    if (c === undefined || c === null) {
        // bye bye performances
        // bye bye security, undefined can be reassigned
        // hello redundant code, == null does exactly the same
        // check in a more secure way since it does not matter
        // if undefined has been redefined
    }
}

Do we agree? That warning in JSLint is one of the most annoying one, at least this is my opinion.
Let's move forward.
If we would like to know arguments length we have different strategies:

function Ajax(method, uri, async, user, pass) {
    if (user == null) {
        // we know pass won't be there as well
        // received probably 3 arguments
        // if user is not null, we expect 5 arguments
        // and we use all of them
    }
    if (async == null) {
        // this is a sync call
        // received 2 arguments
    }
}

function count(a, b, c, d) {
    // not null, we consider it as a valid value
    var argsLength = (a != null) + (b != null) + (c != null) + (d != null);
    alert(argsLength);
    // rather than alert(arguments.length);
}

count();
count(1);
count(1, 2);
count(1, 2, 3);
count(1, 2, 3, 4);

About latest suggestion please consider that only Chrome is slower, but Chrome is already the fastest browser so far while in IE, as example, arguments.length rather than null checks costs up to 6X the time.
Every other browser will have better performances than arguments.length, then we need to test case after case since a function, as String.fromCharCode could be, cannot obviously use such strategy due to "infinite" accepted arguments.
In these cases, e.g. runtime push or similar methods, we don't have many options ... but these should be exceptions, not the common approach, as is for many other programming languages with some arguments support.

Conclusion

I do not pretend to change developers code style with a single post and things are definitively not that easy to normalize for each browser.
Unfortunately, we cannot even think about features detection when we talk about performances, we don't want 1 second delay to test all performances cases before we can decide which strategy will speed up more, do we?
At least we are now better aware about how much these common JavaScript practices could slow down our code on daily basis and, when performances do matter, we have basis to avoid some micro bottleneck.

PHP - apply, call, and Callback class

The "news" is that while some developer is putting a lot of effort to emulate PHP functionalities with JavaScript, I would like to have JavaScript functionalities in PHP.

Nested functions, closures, and injected scope, are only some of JS cool stuff that's currently missing PHP (hoping that during this summer of code someone will implement at least one of them).

Today what I'm going to emulate is a partial implementation of apply and call Function.prototype methods, and this is the basic example:

function apply($name, array $arguments = array()){
    return  call_user_func_array($name, $arguments);
}

function call(){
    $arguments  = func_get_args();
    return  call_user_func_array(array_shift($arguments), $arguments);
}

As is for JavaScript, the main difference between these functions is that apply accept an array of arguments while call accepts an arbitrary number of arguments.

echo call('md5', 'hello world');
// 5eb63bbbe01eeed093cb22bb8f5acdc3

echo apply('pow', array(2, 3));
// 8

Simple, but not so useful yet.
Currently, these implementations are just shortcuts to call_user_func or call_user_func_array PHP native functions ... and these are not JavaScript style friendly ... so what could we do?

To have a JS style code we would like to be able to write something like this:

$md5->call('hello world');
$pow->apply(array(2, 3));

... and I suppose noone could say that this way couldn't be cool, isn't it?
To obtain above behavior all we need is a class, called for obvious reasons Callback, that will contain those 2 public static methods:

class Callback{

    // (C) webreflection.blogspot.com - Mit Style License

    public      $name;      // name of the function
    protected   $_callback; // ReflectionFunction instance

    public function __construct($arguments, $callback = ''){
        $this->_callback    = new ReflectionFunction(
            0 < strlen($arguments)      &&
            strlen($callback) < 1       &&
            is_callable($arguments)     &&
            function_exists($arguments) ?
                $this->name = $arguments :
                $this->name = ''.create_function($arguments, $callback)
        );
    }

    public function __toString(){
        return  $this->_callback->getName();
    }

    public function apply(array $arguments){
        return  $this->_callback->invokeArgs($arguments);
    }

    public function call(){
        // /* simple, unfornutatly with bad performances */ return  $this->apply(func_get_args());
        return  $this->_callback->invokeArgs(func_get_args());
    }
}

What we can do now, is to create every kind of function alias simply sending the name of the function or arguments and body for a runtime function creation.

$md5 = new Callback('md5');
$pow = new Callback('pow');
$sum = new Callback('$x, $y', 'return $x + $y;');

echo $md5->call('hello world').PHP_EOL; // 5eb63bbbe01eeed093cb22bb8f5acdc3
echo $pow->apply(array(2, 3)).PHP_EOL; // 8
echo $sum->call(2, 3).PHP_EOL; // 5

The public name property will contain the string rappresenting the used function name (lambda too), while the magic __toString method will return the name using dedicated ReflectionFunction isntance method (note: lambda functions have everytime the same one: __lambda_func).
With a simple class like this one we are able to send or recieve callbacks between functions, methods, or whatever else ... have you never sent a function in this way?

function hashMe($value, Callback $hash){
 return $hash->call($value);
}

$md5  = new Callback('md5');
$sha1 = new Callback('sha1');

echo hashMe('hello world', $md5).
     PHP_EOL.
     hashMe('hello world', $sha1);

// 5eb63bbbe01eeed093cb22bb8f5acdc3
// 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed

The principal goal is to solve type checks and improve code portability ... but with another little piece of code, this stuff could be even funny!

// Callback dedicated factory pattern function
function callback(){
    static  $Callback;
    if(!isset($Callback))
        $Callback = new ReflectionClass('Callback');
    return  $Callback->newInstanceArgs(func_get_args());
}

With above function we are now able to do something like:

echo callback('str_repeat')->call('hello world ', 2);
// hello world hello world 

Or, to be extremely scriptish, something like:

// create a string with "callback" content
$F = 'callback';

// use them as a function
echo $F('str_repeat')->call('hello world ', 2);
echo $F('pow')->call(2, 3);

// but if we need better performances ...
$md5 = $F('md5');
while($i--)
    echo $md5->call($container[$i]);

Enjoy :)

How to inject protected methods in JavaScript - Part II

As a performances maniac, I've found another way to inject protected methods, or something similar, without unnecessary overload of each public method.

Of course, precedent way is definitively more clear, linear, but if you have a constructor.prototype with a lot of private methods, the overload process will be a wall in front of method execution speed.

Each time you will use a public method, you have to set, and unset, every protected method, and at the same time, as explained in my precedent post, you cannot send the object outside during public method execution, because it will expose every method, protected included.

This new proposal is based on a Function like strategy, applied to instances: apply, and call. Please have a look at this prototype function:

function prototype(constructor, public, protected){
 // webreflection - mit style
 if(protected){
  public.apply = function(callback, arguments){
   return (callback.charAt(0) === "_" ? protected : this)[callback].apply(this, arguments);
  };
  public.call = function(callback){
   return this.apply.call(this, callback, Array.prototype.slice.call(arguments, 1));
  };
 };
 public.constructor = constructor;
 constructor.prototype = public;
 return public;
};

A usage example should be this one:

function MyMath(value){
 this.value = value;
};
prototype(
 MyMath,
 {doStuff:function(){
  return this.value * this.value;
 }},
 {_doStuff:function(){
  return this.value + this.value;
 }}
);

The first sent object will be the prototype of MyMath constructor, while the second one will contain protected methods.

About performances

As you can see in the simple prototype function, there's no override and no overhead for both public and protected methods. This means that you can use a public method directly and without problems:

var num = new MyMath(3);
num.doStuff(); // direct, fast as regular prototype

About protected methods

These simply "does not exists" :)

var num = new MyMath(3);
num._doStuff(); // error

Protected methods are not directly accessible even from instance itself. This means that these methods are safe and not mutable, if used object is created in a private scope, or runtime as showed before.

How to use protected methods

var num = new MyMath(3);
alert(num.call("_doStuff")); // 6

Apply and call, in this case, are used with instance to call a method that, if contain an underscore as first prefix char, will be one from protected prototype, otherwise will be one of the public prototype. Sounds weird?

// full example
function MyMath(value){
 this.value = value;
};
prototype(
 MyMath,
 {doStuff:function(){
  return this.value * this.value;
 }},
 {_doStuff:function(){
  return this.value + this.value;
 }}
);

var num = new MyMath(3);
alert([
 num.doStuff(),       // 9
 num.call("doStuff"), // 9
 num.call("_doStuff") // 6
].join("\n"));

num._doStuff; // undefined

Why do I call them protected

If everyone can call a method, it does not make sense to call them protected.
But this time, the meaning is not the same of classical inheritance, but it is more close to the word itself: proteced.

The main goal is to have a not common or usual way to call methods, specially for libraries developers.
Every API could be based on public methods, while authors could choose to call a protected method when their need them.
This is basically a transparent layer between the developer and the final user: who will use num.call("doStuff") when you can do this: num.doStuff() ?

I know I am not so good to explain my ideas, so I hope someone will find this useful. Have a nice easter ;)