I’ve never been a PEAR fan. My experiences being peripherally involved with the XML_HTMLSax package weren’t encouraging. However, my opinion of PEAR has turned around in recent years thanks to work such as channels in the pear installer and MDB2.

I hope this doesn’t end up a fork. I see little sense in that. I’ll be interested in seeing the PEAR response.

“The bottom line is that security has been set back nearly six years in the past 18 months,” Alan Paller, director of research for the SANS Institute, wrote in an E-mail. “Six years ago, attackers targeted operating systems and the operating system vendors didn’t do automated patching. In the intervening years, automated patching protected everyone from government to grandma. Now the attackers are targeting popular applications, and the vendors of those applications do not do automated patching.”

I’ve advocated better web application installation for a while, but as a usability issue. Increasingly, it is also a security issue. Just another example of why I think the PEAR installer is important. (and why I hope Zend PHP Framework is released on a PEAR channel.)

Chris Shiflet and PHP Developer both have coverage of the webcast. The webcast even caught some attention from the Rails camp.

I won’t try to summarize the webcast here, but instead offer a few impressions.

I found the webcast to be interesting, although it didn’t really answer the primary questions I have about the structure of the front controller and form processing. ZActiveRecord, ZMail, and ZSearch are fine components, but my interest lies in the controllers because that is the area where there is the least consensus about the state of the art. One red flag for me was the suggestion of putting business logic in actions. Nothing but a high level overview was given of the controllers, but this perks my ears as an issue in MVC separation.

The coding standards emphasize not reserving global resources. The framework will not define functions or global constants, it uses exceptions and doesn’t reserve __autoload for its own use. This is very good. On the other hand, it seems to rely on static methods quite a bit, which I think can burn you over the long run if you are trying to offer a componentized architecture and can make code more difficult to test. I’ve been moving away from static methods as much as I can in my own code. Eventually, I always seem to regret using them. They lure you in at the beginning with the promise of simplicity and then they punish you later with their inflexibility.

I wonder how many of the components do their own “connection management” such as with the ZSearch::open (static methods again)? This strikes me as an opportunity for a general dependency injection mechanism. A technique that we are emphasizing more and more in WACT, but which I don’t think has reached widespread use in the PHP framework world.

One of the stated goals of the Zend Framework is to improve the PHP ecosystem. The webcast suggests that Zend PHP Framework will play well with others, allowing you to use the components independently, or for example use a different templating system with the framework. On the other hand, Andi suggested that all components will be distributed in their entirety. When asked if a stripped down version could be distributed, the answer was “Why would you want to?”

I don’t think a monolithic distribution mechanism will play well with the new ecosystem of components that is rising up based on the PEAR installer’s new channel capability. Eventually, the PEAR installer will move into the end user application installation space. To participate in this, ZPF should be available over a channel. I think a key success factor for the Zend framework will be the release of individual components via a PEAR channel.

It is much better to be able to declare dependencies on individual packages, rather than on one huge bundle of components. Monolithic distribution unnecessarily ties together the release schedules of packages that might otherwise have no common dependencies. Micro-packages on a PEAR channel are the future of PHP web application installation.

Overall, I think Zend is taking a good approach to the development of ZPF. I look forward to learning more.

Update: Just as writing tests is an important process element, because testable code is better code, I think that micro package releases are better than monolithic package releases from a process standpoint. The mere act of writing the components so that they can be independently released highlights unhealthy dependencies. This, of course, has to be tempered by an overall vision and cross-package duplicate code elimination. Two areas that have been challenges for PEAR with its political fiefdoms surrounding each package and one reason why PEAR is not a framework.

(P.S. Hurry up and release ZSearch. I want to use it.)

pear install Calendar beta

instead of:

pear config-set preferred_state beta
pear install Calendar
pear config-set preferred_state stable

The thing about defining a coding style standard is that there is no objective means by which to judge one style as “better” or “more-right” than another.

I can think of several objective criteria for judging coding standards practices off the top of my head:

• Does the practice allow more code to be fit on the screen/page at one time (braces on the same line)
• Does the code use white space to emphasize when things should be separate (spaces after commas)
• Can the code written to the standard be viewed in multiple media and multiple editors (spaces not tabs, limited line lengths)
• Does the practice conserve keystrokes (tabs not spaces, no spaces after commas )
• Does the practice facilitate copy and pasting (single statement of code per line)
• Does the practice require extra work to maintain the code (java docs and formatted comment headers are harder to edit beceause of the prefix, aligning equals signs, etc)

Obviously some practices can cause conflicts between criteria. In this case, readability should triumph over key strokes. Practices that require require editing unrelated lines during maintenance should be avoided.

One thing that I have found about refactoring is that no code smell is too small to fix. Having your code in refactored normal form and the process of getting it there by performing small, seemingly unimportant refactorings can reveal the major refactorings that are really worth it. Sometimes the major changes that need to be made are obscured by minor code smells.

Coding styles perform a similar function. Having your code in a “normalized” form frees the mind to consider other aspects of the code. Poorly or inconsistently styled code can obscure refactorings. With a good coding standard, the benefits outweigh having to re-train yourself out of a few habits. I agree with Paul’s conclusion here.

Fortunately, the PEAR standards has made the right decisions regarding these criteria with a couple of minor exceptions and many omissions.

The exceptions as I see them:

• aligning equal signs should be discouraged.
• The braces policy for functions should match that of control structures
• embedding inheritance heirarchy into the class name is bad

UPDATE: Looks I am not the only one who thinks bad style is a bad smell

Hans makes the argument for a tighter vision for PEAR, as well as for an overflow method for packages that don’t fit that vision.

Alan asks if the PEAR group should veto this package?

Lukas Smith offers argument against package redundancy that I can sympathize with.

Because PEAR commits to every package. Thats means if Alan gets run over, Paul dies of old age we are still commited to their packages. Even if they both never go away it still means that the QA team will have to deal with it. It also means that users will have to do alot of research instead of a bit. But I think we have agreed that redundant is bad David?

I wonder if the idea of individual package ownership inhibits the development of a consistent PEAR vision?

I think a Savant veto without an alternate solution to the redundancy that already exists within PEAR will only reinforce the perception of special treatment for the first package on the block.

I think this is a very important debate for PEAR.

This proposal represents an identity crisis for PEAR. Joshua Eichorn recognizes the issue:

Either we have 1 engine and multiple api’s and fix mistakes of the past or we allow competition, this double standard just doesn’t cut it.

Lukas Smith recognizes the issue as well:

So in conclusion if we accept yet another template engine API into PEAR we might as well forget what PEAR currently stands for.

This proposal highlights the cognitive dissonance between the goal of having only one package for a purpose and the reality of already having multiple templating packages in PEAR.

Yet, there are many styles of templates representing different viewpoints and needs. Perhaps this is responsible for the amazing proliferation of template engines in PHP. Can PEAR hope to cover all of these needs with a one size fits all approach? (or even a 5 sizes fit all approach)

Alan Knowles added some Savant features to Flexy and defends fortress PEAR:

Flexy now does _everything_ that Savant does.. – you are basically proposing a competative package, that’s only competative feature, is realistically, that provide a marginally different API…

But Paul Jones, the author of Savant responds by vowing to press forward with the political process:

That is as it may be … however, I am going to continue the proposal and let it come to a vote.

I do not know what this means in terms of PEARs political process. If Savant wins its vote, does this mean that the doors to PEAR are open and that competition is allowed?

Will there be a grand unification of PEAR template engines? Or will the status quo be preserved, confirming the landgrab theory?

In the future it should be possible to automatically build releases and documentation when all the tests pass. Hopefully, this will help improve our record of releasing on the WACT project. With one formal release in nearly a year of active development, our record is dismal as Harry diplomatically points out.

Jon is running Rephlux remotely for WACT right now because we are having a problem getting our full test suite to run in the 8M limit that sourceforge imposes on PHP. We have 97 test cases, 541 test functions, and 1927 assertions in our test suite. This will only grow. The full test suite includes over 350 PHP files when it runs.

Since there isn’t much we can do about unincluding files to free up memory, I decided to take a look at the data that gets stored to see if there was any low hanging fruit there. I wanted to look and see if any of the code we are using keeps any data in global variables that it might be able to release when done to allow the space to be garbage collected.

So, I added a quick and dirty little hack to get an idea of the size of the various global variables that were left over after a test run.

 
    foreach (array_keys($GLOBALS) as $key) {
        echo "$key=" . strlen(serialize($GLOBALS[$key]));
    }
 

 
_PEAR_destructor_object_list=146270
 

 
    function _PEAR() {
        if ($this->_debug) {
            printf("PEAR destructor called, class=%sn", get_class($this));
        }
    }
 

I’ve expressed my opinion of pear.php before and this only reinforces it.

The only PEAR module that WACT requires is XML_HTMLSax, a handy parser for HTML with an XML parsing interface. I’ve always been a little bit uncomfortable with its dependency on pear.php and the deployment issues that this introduces into WACT. WACT also has optional components that reference other PEAR packages, such as PEAR::DB, PEAR::MDB and PEAR::MDB2. Fortunately a more typical WACT use case only instantiates a handful of PEAR objects.