Most days I work on paid projects (or try to), while they sometimes offer an intellectual challenge (like hacking up xul trees in javascript
[it's amazing how javascript is actually usable on Mozilla, rather than the absolute nightmare it is on IE]), or some pleasant company (doing maintenance at a yacht club). It tends to be more the exception than the rule. Most of the day is spent going through lists of changes that have been discussed and modifying databases, interfaces, and ocassionally fixing up someone else's code.
So to prevent insanity creeping in, I try and find something interesting to attack in the evening. In the last few weeks I've had 2 projects ticking away, both of them have big question marks about whether they get finished (like phpmole,DB_DataObjects), or get abandoned in the wastland of muse's (like PHP#, BinaryPHP). Anyway only time will tell.
PintCompiler
Sterling, Thies and a few others, have been busy investigating PHP for Parrot, I had a chance to browse the code a couple of weeks ago. Last time I saw it was at the PHP conference last November, which was a bit chaotic, so although I did start trying to hack up a compiler in PHP to do the same thing, the phpSharp code base I was using wasnt quite ready..
Fast forward 9 months later, having hacked in a Abstract Syntax tree into BinaryPHP, I now had a Tree that parsed PHP code, which could theoretically be refactored quickly to write a generator for any type of bytecode. It took exactly 3 evenings to modify the BinaryPHP tree builder/generator to get the first hello world's working, along with some basic maths etc.
Pint originally had about 6 test PHP files, the most complex a mandelprot calculation however proved to be difficult to implement. Mainly based on a poor assumption I made in designing the code generator. I had assumed it would be a good idea to keep the number of temporary vars down to a minimum, and reuse them where possible. This was a BIG! mistake. Due to the way variables are objects, and need cloning explicity, if you try and reuse a variable and forget to clone, you tend to end up changing the first variable value by accident. Luckly to get it working properly is probably just a matter of reducing the redundant extra clone'ing opcodes, and removing the temporary variable stack code..
http://devel.akbkhome.com/svn/index.php/PintCompiler/DBDO - DB_DataObjects as a PHP extension.
http://devel.akbkhome.com/svn/index.php/dbdo/I had been toying with this idea for a while, DataObjects, while being a godsend for development, has a ended up with little issues that are totally unfixable, while it remains in PHP. some of the biggest being, how to reduce the print_r() size, and how to determine which variables have changed, when building the update/insert requests.
So after spending a week or so looking at potential backends (
libgda,
libdbi and
pdo), My major preference out of all these was libgda, for a number of reasons. Interesting Design, alot of Backends, Great Documentation and it uses the glib/gobject stuff that I've used a couple of times over the years. Although the mailing list is quiet, compared to most of the php ones, the developer's list seemed to be getting things done. It was a close call, there where alot of other deciding factors, libgda's type library was pretty convincing, and introspection features made it pretty compelling.
While no where near completed (and leaking memory like a seive) After 3 late nights, I have alot of what I thought would be the more complex stuff working: - >>>> read the extended entry to find out more (as this intro is long enough).. >>>
dl('dbdo.' . PHP_SHLIB_SUFFIX);loads the baby.
dbdo::saveDataSource("dsn_name","MySQL","DATABASE=test", "test database", "alan","password");
This follows the libdba API pretty closely, and provides a really nice way to configure database connections. Set it up once (or even use the XML format) to store your database config, then forget about it.
Installing it on other machine only has one fixed place to change.
The code that uses it just references the "dsn_name", that you make up, so you can easily merge Database code from other applications, and just configure all the connections for all these to match.
$x = new dbdo("dsn_name","table_name");
Create a database object, and associate with a table (I guess views for postgres should be supported eventually as well.)
class typetest extends dbdo {
function __construct() {
parent::__construct("test","typetest");
}
}
$x = new typetest;
Or you can use the __construct method, in your table specific class (which could be autogenerated I guess)
$x = new mytest;
$x->username = 'find';
$rows = $x->find();
while ($x->fetch()) {
print_r($x);
}
Should generate
select * from test where username ='find' (it doesnt yet, as I've not done the where bit.. - but the rest works)
find() doesnt do much more run the query, and return the number of rows, but what is interesting is the fetch. In the Pure php version, it just overlaid the results onto the object variables, in PHP5, with an extension, it doesnt do any writing of object variables, it just stores them privately hidden away memory (so they dont print_r()).
So how you may ask do you get them?, well the wonders of object overloading, it implements a custom getproperties, and getproperty.
If you ask it for username, it first check to see if you have assigned it manually, otherwise it will return the field from the database result.. (This also means it can keep track easily of what you have changed, when it generates the updates..)
Theres quite a bit of code in there already including
- schema retreival, looking up what the database structure is.
- type juggling, using libGda's types, it knows what to do with dates/strings/ints etc. - so you provide it with a value, and it should be able to convert it into a correct type for the database.
- correct SQL escaping.
Oh well, back to hacking.
