Well, I just finished a new paradigm for data handling in pff. I discovered the ArrayAccess interface in SPL - which is really cool, and then using __get and __set I create a class that can handle data as an array or as an object. Why is this useful? Well, I'm using it for all data in pff - so xml lang files will be read and stored in this format, and db queries are read in this format. It makes for very nice access to data. Single "rows" of data are stored in the data class, I also added sorting and filtering functionality. Multiple "rows" of data are stored in a the collection class, which allows multiple sorting and filtering, and returns pff_data objects when you request a "row" - probably row isn't the best term but until I come up with something better, it'll stay.
I'm very pleased with the way data access works using these tools, $data->id and $data[
id'] and $data will all get you the same information, which means you don't have to worry about how you use a query returned, or worry about telling it to grab and object, or assoc array, or num array, it's basically three in one.
The filtering is also very useful because pff implements query caching - so you can do an overall query and then filter by something in the app and use the same cached query over and over again. I've been considering taking the limit out of the database stuff and putting it in the collection stuff, but I'm not sure about that yet.
Caching is being implemented for EVERYTHING in pff - which means if you DON'T use caching the app isn't quite so speedy, just because there's so much going on. but if you cache the registry, and cache queries, and cache hooks files, and cache pages, and cache templates page generation is a LOT quicker and easier.
I had a lot of fun with the caching interface, because it means you could write any sort of caching utility. Right now I have containers for shmop, shm, memcache, and files. I might do a db one later, but db caching will always have more overhead.