[PHP] Strict error on static call? Solved!

Just a quick post about Strict standard error when we have a class method which would like to behave differently if called statically.
Apparently, and this is a truly old bogus I opened ages ago, the solution was to supress Strict errors (lol, thanks developers) even if in every other programming language, via overload, this kind of situation could be solved in a bit.

How to solve the problem?

While last post I suggested a couple of runtime solutions, this time I suggest to simply avoid the method definition and use a different one with a meaningful name. In this example I created a String class:

class String {

    // choose a recognizable name for protected method
    static  protected   function    _concat(array $arguments){
        return  new self(implode('', $arguments));
    }

    // use magic __callStatic function
    static  public  function    __callStatic($name, array $arguments){
        // check the recognizable name
        switch($name = '_'.$name){
            case    '_concat':
                // return its call
                return  self::$name($arguments);
        }
    }

    protected   $__value__; // save the string somewhere

    // assign initial string, if any
    public  function    __construct($__value__ = ''){
        $this->__value__ = $__value__;
    }

    // use magic __call method
    public  function    __call($name, array $arguments){
        // check the recognizable name
        switch($name = '_'.$name){
            case    '_concat':
                // normalize expected arguments
                array_unshift($arguments, $this->__value__);
                // return its call
                return  self::$name($arguments);
        }
    }

    // this is a String class ... 
    public  function    __toString(){
        return  $this->__value__;
    }

}


// test the alchemy
$str = new String('Hello');
var_dump(
    String::concat('Hello', ' ', 'World', '!') == $str->concat(' ', 'World', '!')
    // true, both are Hello World!
);

As we can see, errors are gone and the code is much easier to maintain. Hope this will help (performances? ... oh, come on!)

[js.php] A JavaScript Object Like PHP Class

PHP 5.3 introduces the Closure class which is really useful and more powerful than good old lambdas via create_function.
These are main limits of Closure class:

• you cannot serialize a Closure instance (and json_encode does not solve the problem at all)


• you cannot inject scopes via $this unless the closure comes from a class method

While with an emulated prototype style class, something I tried months ago as well, the first point could not be a problem, to solve the second one is quite inevitable to use a Python like variable as first argument, called $self, to make the Closure both portable and re-adaptable.

JSObject :: JavaScript Object Like PHP Class

/** js.php basic JSObject implementation
 * @author  Andrea Giammarchi
 * @blog    WebReflection.blogspot.com
 * @license Mit Style License
 */
class JSObject implements ArrayAccess {

    // public static prototype
    static  public  $prototype;

    // ArrayAccess Interface
    public  function    offsetExists($index){return  isSet($this->$index);}
    public  function    offsetGet($index){return  $this->$index;}
    public  function    offsetSet($index, $value){$this->$index = $value;}
    public  function    offsetUnset($index){unset($this->$index);}

    // Invoked lambdas via $this or self::$prototype
    public  function    __call($index, array $arguments){

        // inject $this as first argument
        array_unshift($arguments, $this);

        // invoke the callback
        return  call_user_func_array(
        
            // if it has been assigned to the object itself
            isset($this->$index) ?

                // it has priority
                $this->$index :
                
                // otherwise invoke from self::$prototype
                self::$prototype->$index
            ,
            $arguments
        );
    }

    // JS like behavior, ready for extends
    public  function    __toString(){
        return  '[object '.get_class($this).']';
        // e.g. [object JSObject]
    }

    // Relevant Global Object implementations
    public  function    getPrototypeOf(){
        return  get_class($this);
    }
    public  function    hasOwnProperty($index){
        return  isset($this->$index);
    }
    public  function    isPrototypeOf(/* string */ $class){
        return  $this instanceof $class;
    }
    public  function    toSource(){
        // we could implement __sleep and __wakeup
        // to avoid closure serialization (not possible yet)
        return  serialize($this);
    }
    public  function    toString(){
        return  $this->__toString();
    }


    // not standard method, anyway useful
    public  function    toJSONString(){
        // we could parse properties in a foreach
        // to filter meaningless closures, if any
        return  json_encode($this);
    }
}

// the global prototype is a JSObject too
JSObject::$prototype = new JSObject;

// JSObject factory: e.g. $myobj = JSObject(); // rather than new JSObject;
function JSObject(){
    return  new JSObject();
}

Above class uses an interface from the great SPL, an in-core extension present since PHP 5.1
The rest is theoretically compatible with old style lambdas, static functions, or new Closure instances. Here we go with some example:

// we can assigns prototypes everywhere ...
JSObject::$prototype->getName = function($self){
    return  $self->name;
};

$o = JSObject();

// ... even after JSObject instances creation
JSObject::$prototype->writeAge = function($self){
    echo $self->getName().' is '.$self->age.' years old.';
};

// assign properties
$o->name    = 'Andrea';
$o->age     = 30;

// test some JS method
echo    $o->toJSONString();
// {"name":"Andrea","age":30}

echo    $o;
// [object JSObject]

echo    $o->toSource();
// O:8:"JSObject":2:{s:4:"name";s:6:"Andrea";s:3:"age";i:30;}

// or tests runtime methods
$o->writeAge();
// Andrea is 30 years old.

// we can assign a custom method runtime
$o->getSurname = function($self){
    return  'Giammarchi';
};

// custom methods have priority over prototype
$o->getName = function($self){
    return  $self->name.' '.$self->getSurname();
};

$o->writeAge();
// Andrea Giammarchi is 30 years old.

Is it cool? And more is coming for backward compatibility:

// prototype via function name resolution
JSObject::$prototype->getName = 'JSObject_getName';

// the function with a prefix to avoid conflicts
function JSObject_getName($self){
    return  $self->name;
}

// a simple test case
$o = JSObject();
$o->name    = 'Andrea';

echo    $o->getName();
// Andrea

And obviously we can do the same with create_function:

// prototype via lambda
JSObject::$prototype->getName = create_function('$self','
    return  $self->name;
');

Conclusion

Via SPL, closures, and some convenient trick, we could completely change the code style of PHP. Performances are always a priority, in any case, but with a couple of good practices, some discarded or "language useless" piece of ECMAScript, we could use JS style as low level structure for more Object Oriented frameworks or completely different ways to code.

What's next?

It is ages that I am waiting for a stable PHP 5.3 plus PECL extensions (in particular the php_operator to add operator overloads) to be able to create a JavaScript version of PHP. I have already created similar classes and my vision is a one2one JavaScript style framework created entirely via PHP. Craziness? Non-sense? Dunno, just try to imagine a Jaxer like behavior in every host with "just" PHP support ... is it a cool idea? Well, please contact me if you are interested ;)

[IE8] Global constants via defineProperty ... Illusion!

I do not want to spend a single word about Internet Explorer 8 Object.defineProperty implementation, which works only with DOM prototypes and the super global window but not with user defined objects, as __defineGetter__ and __defineSetter__ do since ages:

Standards are an important factor to ensure browser interoperability for the Web developer (n.d. oh, really?!??!?!!!!). The accessor property syntax has only recently begun standardization (you guys have a weird concept of the time ... or the meaning of "recent" in IT therms ...). As such, many browsers support an older, legacy syntax ... (n.d. which at least has dignity to work with every kind of object ... )

Anyway, few things are better than nothing, so welcome to Object.defineProperty!

Let IE8 behaves like every other or change every other to respect new M$ standard?

This was the first question when I thought about this new global function: does it mean we finally have a way to emulate __defineGetter__ and setter in Internet Explorer as well? First of all: NO, since IE implementation works only with DOM and window, secondly, we need to add an Object.prototype method (to be honest ... two) and we all know that Object.prototype is the "untouched one".
So, let's do in the other way, we can add a method to the global function Object, which is less obtrusive and more compatible ^_^;;

if(!Object.defineProperty && Object.prototype.__defineGetter__)
    // a silly WebReflection idea
    Object.defineProperty = function(obj, prop, getset){
        if(getset.get)
            obj.__defineGetter__(prop, getset.get);
        if(getset.set)
            obj.__defineSetter__(prop, getset.set);
    };

Well done, now we should simply parse every passed obj to understand if those are IE8 compatible ... is it worthy? ... dunno yet, just for fun, destroy IE8 environment with this evil Object.prototype if you want:

if(!Object.prototype.__defineGetter__ && Object.defineProperty){
    // the second silly WebReflection idea!
    Object.prototype.__defineGetter__ = function(prop, get){
        Object.defineProperty(this, prop, {get:get});
    };
    Object.prototype.__defineSetter__ = function(prop, set){
        Object.defineProperty(this, prop, {set:set});
    };
};

Same problem, we cannot use a method with every browser ... the only good part of this global Object method is described in this msdn page, an addEventListener, finally, for IE8 too and every node without usage of wrappers (usually the $ object ...)

The insane idea: Global Constants for EveryBody?

... oooOOOOOOOO Crap! Even if we can do something like this:

// create the evil plan!
Object.defineProperty(
    window,
    "nobodyCanChangeMe",
    {
        get:function(){
            return "I am like a constant!";
        },
        set:function(){
            throw new Error(
                "You cannot change a constant, don't ya know it?"
            );
        }
    }
);

// test the evil plan! (muHaHAHAHA in the background ...)
nobodyCanChangeMe = 123;
// Error: You cannot change a constant, don't ya know it?

You will probably be (un)surprised to know that Internet Explorer 8 (tada, tada, taDAAA!!!) completely ignore the setter whenever you decide to redefine the property!!!

// above perfect evil plan code ... plu ...

Object.defineProperty(window, "nobodyCanChangeMe", {get:function(){
    return "you must be joke!";
}});
alert(nobodyCanChangeMe); // you must be joke!

As Summary

VBScript via browser supports constants since dunno how many years. I personally wrote a PHP define like functions ages ago but nothing, Microsoft decided to release IE8 without constants, which are supported almost by evey other (FireFox, Chrome, Safari, Opera -- buggy/meaningless in the latter case) so there is no way to protect our code for JsonP requestes, safe evaluations, whatever you would like to be "99%" sure nobody can change, etc etc ... so this is a thank to IE Team, they worked hard, but this is also a: was it that difficult to put more effort in the JavaScript engine, rather than scam the world with those useless page loading benchmarks?

Enjoy the new Web 2.IE8 Era!