[KrisJordan]

Interested in everyone's plans with PHP 5.3. The codebase is significantly faster than pre-5.3 and there are some new features that really improve software engineering in PHP (namespaces are a big win for framework interoperability, other features like late-static binding and lambdas can really clean up interfaces).

As you've read on the blog we've been busy preparing a 5.3 specific branch of Recess that leverages these new features to make Recess even more light weight.

[Jamie Rumbelow]

I'm interested in finding out how backward compatible this release is - I'd love to start using it, but I'm afraid it will break everything (as installing Ruby1.9 did). How compatible is this release?

I still don't think that this branch will take off though - it took years for us to see PHP5 adoption, so I think it'll be a long time before PHP5.3 gets widespread usage, and in that case I think everybody will use PHP6, which will undoubtedly be released by then.

[KrisJordan]

Backwards compatibility isn't as big of an issue with 5.3 as it was for 4 to 5. There are some deprecated functions (like split which was much slower than explode and preg_split) and some deprecated features (like safe_mode, that was really broken anyway). For your regular 5.x scripts you should see a significant performance improvement upwards of 10-20% by making the switch.

The reality is, though, that 5.3 is "the future" of PHP. From my understanding, PHP 6.0 is PHP 5.3 + unicode. Positioning for 5.3 means positioning for 6.0. Its inclusion of namespaces (which work quite well and are not nearly as awkward as they initially looked) are a godsend from a software engineering point of view. Namespaces plus simple class loading schemes should bring uniformity and interoperability to libraries without resorting to awful, awful class names. Late static binding and lambdas are big wins for terse, expressive, flexible code. For a Recess branch this means we can get remove a lot of code (Library is replaced with namespaces and a simple class loader), simplify code (having late static binding means we don't need instances of models to kick off queries in the ORM, for example, there are places internally where lambdas clean and speed a lot up, too), and be more powerful

(Person::all()->each(function ($person) { echo $person->name."<br />"; });)

all at once.

Recess is still a small community made up primarily of developers who love the art and joy of programming. Really smart developers who are tired and wary of PHP as it was in 2006. Developers who have barely managed to hold on while waiting for 5.3 to be released after what felt like an eternity, and developers coming back to PHP from other languages with an appreciation for concepts like meta-programming and lambdas. Recess developers want to enjoy development as much as possible. PHP 5.3's speed and power make PHP development on the whole, much more enjoyable. This is why we're doing a 5.3 branch.

[Jamie Rumbelow]

Touché, that was a pretty impressive speech, and the PHP5.3 features look pretty damn sweet. I guess I took it for granted, and it shows my ignorance that I though the 5.3 branch would fail. I'll pull it and have a play about pretty soon and give you the verdict - I've just got to figure out how to get the damn thing running on MAMP...

[Rafał Filipek]

PHP 5.3 is so cool. I can't wait for php 5.3 recess branch. I like Your example Kris. Now we can code in jQuery style:P

<?php

class people {
	
	private $data = array();
	
	public function all(){
		$this->data = array(
			0 => array('name' => 'Rafał', 'surname' => 'Filipek'),
			1 => array('name' => 'John', 'surname' => 'Doe'),
			2 => array('name' => 'Someone', 'surname' => 'Else'),
			3 => array('name' => 'Recess', 'surname' => 'Framework')
		);
		return $this;
	}
	
	public function each($function){
		$surnames = array();
		foreach($this->data as $element){
			$surnames[] = $function($element);
		}
		return $surnames;
	}
}


$people = new people();

$people->all()->each(function($p){ echo $p['surname'] . '<br />'; });

echo '<hr />';

$surnames = $people->all()->each(function($p){ return $p['surname']; });

var_export($surnames);

?>

[KrisJordan]

JQuery's use of chaining and fluent interfaces has been (and will continue to be) a big influence on the chaining technique in the Recess ORM. Great example code that makes me realize we've got some interesting options when it comes to returning values from each.

What would you expect the result of your var_export to be? An array of values? Could we do better?

If it were another type of object (like a PDODataSet) we could continue the ability to chain in interesting ways. Would love to see what kinds of scenarios we could come up with for uses of higher order methods, like each, in the ORM.

Work on the 5.3 branch is going well, just about have the low level internals taken care of and fully tested. More news and a preview of the branch will be out soon.

[Rafał Filipek]

Quote

What would you expect the result of your var_export to be? An array of values? Could we do better?

Hmmm, in fact I wasn't thinking about that. In my opinion 'each' function should return an array of any kind of elements, that were returned by function which been passed to it.
OT: Sorry for this sentence my english is not so good . EOT
For example if we assume that it's not allowed to return model rows mixed with other types like string or smth like that it could be PDODataSet or array. First element returned by "each" function, may decide which one will be used and returned. In that case there are many ways to use "each" method. YOu can return just a list of column values for specified or all rows or same set of rows with some modifications ( and save them for example ).
This is just my first thought so it could be meaningless