being working a lot with mootools, dojo, wordpress and some other frameworks and toolkits lately, my question today is this:
Why, most of the times, don’t frameworks and toolkits developers launch any backward compatibility modules at all?

It might seem pretty complicated getting old deprecated funcionalities working  on newer, better versions, but, apart from some real specific embembed funcionalities, it really shouldn’t be that hard.

For the following example i’ll use Mootools as an explanatory example:

All you need is a nicely designed dynamic version transitioning system.
One that allows you to, anytime on the execution, define which version will the following code run on.

Imagine you design a backward compatibility plugin from version B to version A.
On version C you’ll design a backward compatibility plugin to version B.

So now, on a page running “mootools-C.js” you should include the backward compatibility modules “mootools-back-C-B.js” and “mootools-back-B-A.js”, or a compiled version (having just a copy paste of both previous files content) “mootools-back-C-to-A.js”.

So if you run something like “Mootools.use_version(‘A’);” the dynamic version transitioning system would automatically look for it’s previous version compatilities execution for version B at, let’s suppose, “MootoolsBack_C_B();” and then rerun the same command (“Mootools.use_version(‘A’);”) while already running on version B to travel back to version A (the dynamic version transitioning system, already on version B would run something like “MootoolsBack_B_A();”).

This method would, in theory, work for multiple version transitions without having to design a specific plugin for each version to version compatibility. It would save developers hours in trying to put two different tools, based on two different framework/toolkit versions, together on the same execution – like using both MOOdalbox 1.3 beta 2 and mooflow v0.2 in the same page.

The system would work both ways, as you could “Mootools.version_reset();” or “Mootools.use_version(‘C’);” to travel back to version C on the rest of the execution, the system would run the consecutive version travel functions eg. “MootoolsBack_A_B();” and “MootoolsBack_B_C();” and the rest of the code would be running on Mootools version C.

This “dynamic version transitioning system” will be used for every release transition on NaturePhp.
It might not work perfectly at first, but it will certainly relieve many developers’ headaches.

I hope in the future more and more projects start using a system like this.

- ok, so it’s a biased opinion… :/

NaturePhp itself is basically a plug-in system for the coolest functionalities around – most of the upcoming functionalities are either gathered from wordpress, joomla!, CodeIgniter and others, as well as a few of our own – *and a few RubyOnRails original ideas implemented in php ;)

The functionalities are organized into classes, and the classes are organized into namespaces, providing a great deal of “space” for future plug-in developments.
It uses __autoload() for all classes, meaning it is just as fast no matter how many plug-ins you have installed.
NaturePhp does not aim being labeled as a framework, but, being a pluggable toolkit itself, it allows future developers to build their own frameworks as plug-ins. – The idea is to provide a stable ground for common development and lot’s of easy to use functionalities for developers – much like Phyton’s libraries.

We are currently using Namespace_Class::method() instead of Namespace::Class::method() and Class::callStatic($func_name, [$arg1, $arg2... $argN]) instead of Class::func_name([$arg1, $arg2... $argN]) to workaround the lack of “Namespaces” and method overloading “__callStatic()” support on PHP 5.2.6, as these two features are required for most of the toolkit functionalities.
It’s ugly, but it keeps the toolkit usable and developed while we wait for PHP 5.3.0.

As soon as PHP 5.3.0 comes out we’ll implement the necessary namespaces and change all the Class::callStatic($func_name, [$arg1, $arg2... $argN]) calls to Class::func_name([$arg1, $arg2... $argN]) – so probably a couple of weeks after PHP 5.3.0′s release we’ll have a NaturePhp 0.1 out ;)

While we wait, we’re also finishing the NaturePhp’s website at http://naturephp.org ;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Test{
 
    //public props
    public $var1="Value 1";
    public $var2="Value 2";
    public $var3="Value 3";
 
    //private props
    private $var4="Value 4";
 
    //public method
    public function public_function(){
         return true;
    }
 
    //private method
    private function private_function(){
         return true;
    }
 
}

You can cycle through the public object properties as you would with an array:

1
2
3
4
5
6

$test=new Test();
 
foreach($test as $prop_name=>$prop_value){
    print $prop_name.'=>'.$prop_value;
    print "<br".">";
}

The result will be:

var1=>Value 1
var2=>Value 2
var3=>Value 3

Why?

- Autoload libraries ( Modules – similar to naturePhp’s toolkit system ) is a default system;
- a small core;
- namespaces and modules;
- indentation is used to mark out block structure rather than curly braces – much cleaner code;
- everything is a reference!
- a simple array slicing syntax;
- lambdas and other built-in functional programming constructs;

I always asked myself why Google uses so much python, now i know.

I’ll still be working on naturePhp and with PHP in general, i still think PHP is much more easy to setup and learn, as well as more resourceful, and most of the shared server environments use PHP, so naturePhp toolkit is continuing to be a must have – especially with the oncoming namespaces on PHP 5.2.3 ;)