If you've ever had the "pleasure" of working with hardcore-Java types, you'll likely chuckle at the following:
“Maybe while the Java world was engaged in talking of high end, super techie stuff, with the words 'enterprise', 'transactions' and 'SOA' embedded in every sentence, the PHP guys actually went out and created a lot of simple yet very useful software.”
— (from: http://indicthreads.com/blogs/161/Java_PHP_CMS_Comparison.html)
After more than 2.5 years of inactivity (well, when it comes to releases, anyway), I've finally released PEAR::Mail_Mime v1.3.0RC1.
If you use Mail_Mime (or even if you don't), please download and test it. It's my first PEAR release, but it seems to have gone well -- I'm a little nervous about breaking something, though. I've personally fixed a lot of bugs, and I know that Cipri and George (and others) have fixed a large number, as well (before I took the reins).
If you're feeling especially helpful, we could always use more unit tests. Oh, and don't be shy about sending bug reports.
Thanks in advance!
Well, definitely not PHP related, but...
Anyone else noticed that Ebay's affiliates have been a little over-zealous in their ads, lately?
Babies for sale... [img]http://blog.phpdoc.info/uploads/adsgonewrong.png[/img]
Google for "bombs"... [img]http://blog.phpdoc.info/uploads/adsgonewrong2.png[/img]
(my wife pointed out the "babies" one)
Weird stuff.. (-:
I was reminded, this past week, of how cool the tokenizer is.
One of the guys who works in the same office as I do had what seemed to be a simple problem: he had a php file that contained ~50 functions, and wanted to summarize the API without parsing through the file, manually, and cutting out the function declarations.
We introduced him to in-line phpdoc blocks (he works (as a Jr.-level PHP developer) in the same office, but for a different company, so he doesn't have to follow our coding standards, but I digress..), but the 50-function library in question didn't have docblocks.
Sure, he could (and did) pull up a list function NAMES with get_defined_functions (I assume by using array_diff against a before-and-after capture), but this didn't give him the argument names, or even the number of arguments for a given function, so I broke out some old tokenizer code I'd written.
In case you aren't familiar with the tokenizer, the PHP manual defines it as:
“[an interface to let you write] your own PHP source analyzing or modification tools without having to deal with the language specification at the lexical level.”
The extension (which has been part of the PHP core distribution since 4.3.0) consists only of two functions: token_get_all and token_name, and a boatload of constants.
Enough babble, though, let's get to the meat. I pulled out this code I'd written for PEARClops (on EFNet #PEAR) that parses PHP source files and figures out what classes, functions/methods and associated parameters are included.
[php] $tokens[$i][1], 'class' => $currClass, ); } else { $thisFunc['params'][] = array( 'byRef' => $nextByRef, 'name' => $tokens[$i][1], ); $nextByRef = FALSE; } } elseif ($tokens[$i] == '&') { $nextByRef = TRUE; } elseif ($tokens[$i] == '=') { while (!in_array($tokens[++$i], array(')',','))) { if ($tokens[$i][0] != T_WHITESPACE) { break; } } $thisFunc['params'][count($thisFunc['params']) - 1]['default'] = $tokens[$i][1]; } } $funcs[] = $thisFunc; } elseif ($tokens[$i] == '{') { ++$classDepth; } elseif ($tokens[$i] == '}') { --$classDepth; }
if ($classDepth == 0) { $currClass = ''; } }
return $funcs; }
function parse_protos($funcs) { $protos = array(); foreach ($funcs AS $funcData) { $proto = ''; if ($funcData['class']) { $proto .= $funcData['class']; $proto .= '::'; } $proto .= $funcData['name']; $proto .= '('; if ($funcData['params']) { $isFirst = TRUE; foreach ($funcData['params'] AS $param) { if ($isFirst) { $isFirst = FALSE; } else { $proto .= ', '; } if ($param['byRef']) { $proto .= '&'; } $proto .= $param['name']; } } $proto .= ")"; $protos[] = $proto; } return $protos; } echo "Functions in {$_SERVER['argv'][1]}:\n"; foreach (parse_protos(get_protos($_SERVER['argv'][1])) AS $proto) { echo " $proto\n"; } ?> [/php]
Save it as "parse_funcs.php" (or whatever you like) and call it like so:
php parse_funcs.php /path/to/php_file
For instance: [code] sean@iconoclast:~/php/scripts$ php token_funcs_cli.php ~/php/cvs/Mail_Mime/mime.php Functions in /home/sean/php/cvs/Mail_Mime/mime.php: Mail_mime::Mail_mime($crlf) Mail_mime::__wakeup() Mail_mime::setTXTBody($data, $isfile, $append) Mail_mime::setHTMLBody($data, $isfile) Mail_mime::addHTMLImage($file, $c_type, $name, $isfilename) Mail_mime::addAttachment($file, $c_type, $name, $isfilename, $encoding) Mail_mime::_file2str(&$file_name) Mail_mime::_addTextPart(&$obj, $text) Mail_mime::_addHtmlPart(&$obj) Mail_mime::_addMixedPart() Mail_mime::_addAlternativePart(&$obj) Mail_mime::_addRelatedPart(&$obj) Mail_mime::_addHtmlImagePart(&$obj, $value) Mail_mime::_addAttachmentPart(&$obj, $value) Mail_mime::get(&$build_params) Mail_mime::headers(&$xtra_headers) Mail_mime::txtHeaders($xtra_headers) Mail_mime::setSubject($subject) Mail_mime::setFrom($email) Mail_mime::addCc($email) Mail_mime::addBcc($email) Mail_mime::_encodeHeaders($input) Mail_mime::_setEOL($eol) [/code]
Not bad, huh?
There are some not-so-obvious bugs (inheritance, mostly), but for a relatively short script, it does a pretty good job.
My pet project du jour has to do with PHP, commits and RSS. I'll talk about it here when it's ready, but in the mean time, here's a teaser.
Part of what I'm doing is putting commit data into a database. Since I'm re-architecting my database schema and access methods, I figured that this would be the perfect opportunity to try PDO.
(UPDATED below)
Here are my first impressions.
Let me say, first, that I think PDO has a LOT of potential. Even the work that has already been completed is wonderful, and it will push PHP forward into even heavier usage. I used to write CFML (please don't hold it against me), and one of the key benefits of Coldfusion was uniform database connectivity.
Additionally, I've never been able to do cool things like use prepared queries in MySQL before, and while it's not technically possible to actually do this in (at least in the version I run -- see below), PDO's emulation layer is an incredible idea that I'm going to have a hard time living without at work (where we're still on PHP 4.. at least for the next couple months).
In short: PDO is great. It will become an indispensible part of the PHP core distribution. Kudos to all involved.
I'm running PHP 5.0.3 with php checked out from PECL CVS. The database I maintain on that box is MySQL, so I grabbed both PDO and PDO_MYSQL. I used the phpize method, and then stuck the extension=*.so directives in my php.ini.
So far so good.
The version of MySQL I have installed is that which is part of Debian stable: MySQL v3.23.
Here's where the going got rough. I was (apparently) the first to try PDO on this version of MySQL. The first time I constructed a PDO object, an exception was thrown, which lead to PECL bug #3470.
Wez has been not only instrumental in creating PDO, but also extremely helpful in diagnosing/confirming (or bogussing (-: ) the problems I've had.
So, I commented out the offending line that caused the constructor to fail (and I see that this has been fixed in CVS, but I'm unable to test, currently (again, see below)), and continued working on my project.
The prepared statements are REALLY nice. I can't say I've ever had such an enjoyable experience with MySQL access (except for DBDO).
I ran into three more issues. The last of which leaves me unable to use PDO in its current state (in CVS).
All in all, PDO is going to be great. Hopefully in time for PHP 5.1 (tentatively March 1st). I'd even suggest postponing 5.1 if PDO still has major bugs.
PDO_MYSQL isn't what I'd consider production/release quality, currently, but these bugs seem like they'll be easily overcome. I think it needs more testers -- what I've found broken, I've reported, but some of this stuff I was quite surprised to find that I'm the first to discover the flaw.
It seems that with PDO, MySQL was largely overlooked (the absence of a PDO_MYSQLI attests to this), and I'm certainly not one to extoll the virtues of MySQL, many PHP users know nothing else, and we'd be well-advised to make PDO_MYSQL as smooth as possible.
... anxiously awaiting a stable PDO and 5.1. Again, great work, guys.
UPDATE: Following Wez' suggestion in bug #3549, (but also additionally actually removing the previously-instlaled pdo*.so files), I was able to get PDO working in its current state (from CVS).