DC PHP

I will be flying out this weekend for my first speaking engagement at The 2008 DC PHP Conference. In looking at the speakers list there are a few familiar faces and quite a few new ones so it should be a fun experience all around. I will be giving 2.5 talks this year. One on Beginning PHPUnit Testing, another on Advanced PHPUnit Testing and then I will be giving a joint presentation Andrew Minerd, a co-worker of mine, on distributed CLI processes.

I am fairly excited as this is not only my first time speaking at a PHP conference but it is also the first time I have been to Washington DC. I have a profound respect for the early history of our country and I am looking forward to seeing the some of the landmarks honoring that history. In any case, if you are going to be in DC for the conference be sure to track me down, I shouldn’t be too hard to find.

Continue reading

Share
Posted in PHP | 2 Comments

Las Vegas PHP Group: It’s Alive

As promised, a couple of days ago the LV PHP User Group had its first meeting. The purpose of the meeting was to see what kind of interest there was and to gather some ideas for future meetings. We had a pretty good turnout for our first meeting. I think around 20 or so people attended and we mingled and talked amongst ourselves for around 2 hours.

We are going to be having another meeting in mid to late may. The current plan is that two of us will be doing a couple of short talks, I will be talking about testing and quality assurance. We also talked about getting involved in the PHP TestFest project. The last thing we decided is that the next meeting will be in a ‘quieter’ environment. PT’s Pub worked well for a meet and greet type of meeting but would be a tad loud for any kind of presenting. It also forcluded some people from attending due to the atmosphere.

When I hear more info about dates I will post it. For those of you that live nowhere near Vegas, maybe you can use us as a way to writeoff a vacation as a business expense? :D

Posted in PHP | 3 Comments

Las Vegas PHP User Group

I am pleased to announce that Las Vegas finally has a PHP User Group and our first meeting is…tomorrow. I am pretty excited as I know there is a fairly decent size PHP programmer community in LV, it just hasn’t been organized yet. One of my co-workers Ray Lopez is organizing the group and it looks like we’ll have a fairly decent size group at our first meeting. If you are from Las Vegas I would encourage you to attend if at all possible! If you are unable to attend then I would highly recommend you still sign up at meetup.com so you can keep informed of future meetings.

Time:
Friday, Apr 11, 2008, 4:00 PM

Place:
PT’s PUB

310 E. Warm Springs Rd.
Las Vegas, NV 89119
Directions

Posted in PHP | 6 Comments

Late Static Binding (LSB) forward_static_call()

I finally freed up some time to finish some quick tests for some of the late static binding patches I made and one of them finally made it into head.

The original post I had bringing up this issue was lovingly title Late Static Binding…Sorta. Basically the original patch alone did not provide a means to override a method, forward execution to the parent method and still preserve the ability for static:: to be anything meaningful. It would be turned into the syntactic equivelant of self::. I came up with a few patches to address this. After several rounds of back and forth about the patches the conversation died out with no decision. I finally resurrected the topic and was able to find concensus for the third patch (forward_static_call()).

This weekend I wrapped up a few small tests and sent the patch in and it was subsequently pushed to php 5.3 and php 6.0. Now, this is not at all the way I wanted things to work, in all honesty I think the patch is pretty hokey but unfortunately nobody really spoke up in support of the changes I wanted to make to parent:: in regards to LSB. So I thought it far more important to make sure there was a way to make sure static methods could be overridden while ensuring that access to parent methods would be unabated.

So now, if you want to override a static method and forward execution to the parent class, the safe way (in regards to static inheritance) is shown in Table2 while the (unfortunately) not so safe way is shown in Table1:

<?php

class ActiveRecord
{
    public static funtion loadById($id, PDO $db)
    {
        $table = get_called_class();
        $statement = $db->prepare("
            SELECT * FROM {$table}
            WHERE {$table}_id = ?
        ");
       
        $statement->execute(array($id));
        $column_values = $$statement->fetch(PDO::FETCH_ASSOC);

        if ($column_values)
        {
            $ar = new static($db);
            $ar->column_values = $statement->fetch(PDO::FETCH_ASSOC);
            return $ar;
        }
        else
        {
            return FALSE;
        }
    }
}

class Table1 extends ActiveRecord
{
    public static function loadById($id, PDO $db)
    {
        /**
         * DANGER! the table name will resolve to ActiveRecord
         */
        $ar = parent::loadById($id, $db);

        if ($ar === FALSE)
        {
            return new static($db);
        }
    }
}

class Table2 extends ActiveRecord
{
    public static function loadById($id, PDO $db)
    {
        /**
         * SAFE WAY! the table name will correctly resolve to Table2
         */
        $ar = forward_static_call(array('parent', 'loadById'), $id, $db);

        if ($ar === FALSE)
        {
            return new static($db);
        }
    }
}

?>

This shows an example of the differences between using parent:: and forward_static_call. I really do wish that the behavior of parent:: would just be modified to work like forward_static_call does. It would be alot less awkward and imo closer to what the average oo programmer would expect. I suppose the issue is up for debate if anyone feels like bringing it up on internals, we aren’t stuck with it until php 5.3 rolls :). The patch is even available it just needs some more vocal supporters.

In either case at least there is a way around it now…

Posted in PHP | 9 Comments

Late Static Binding – Changes to parent

If you have been following the PHP internals list for the last few weeks you probably have seen a discussion concerning the current behaviour of late static binding (lsb) and how it seems to be unnecessarily limited when it comes to inheritance. I first posted about the limitations of the current lsb implementation as it relates to inheritance in Late Static Binding…Sorta. It has since been revived in this thread on the internals mailing list: RE: [PHP-DEV] late static binding php6.

I won’t rehash all of the arguments as you can quite easily find out my full thoughts by previous posts and on that mailing list thread. To put it simply I feel that somehow there needs to be a way to call methods in a parent class without losing the ability to reference back to the original called static.

<?php

class A
{
    public static function test()
    {
        echo get_called_class(),"\n";
    }
}

class B
{
    public static function test()
    {
        //do additional work ...
        parent::test()
    }
}

B::test(); //outputs B

?>

This (or anything like it) is currently impossible in the current lsb implementation. I spent a bit of my extended weekend preparing three different patches to work around this problem. I just now sent them to the internals mailing list so they can be discussed. You can view this email and get a summary of the patches by viewing my recent php-dev posting.

All of the above patches are against 5.3. I was having some strange problems with the test suite in php6 so I moved onto php5.3 so I could make sure things weren’t breaking on me :P. If anyone reading this feels as strongly as I do that there should be a way to do this I hope to encourage you to make your thoughts known on PHP-Dev.

Posted in PHP | 5 Comments

ZendCon07 Day 1

Day one of the conference is over and everything has gone well so far. I attended the extending PHP session by Wez, Sara, and Marcus. It was alot of review but it was very

informative and brought up alot of things that I tend to forget frequently. It was also good to find out that Marcus has a pretty decent american impression. In either case I

have a couple small php extension projects that I am thinking about starting now just to tinker around with some of what they talked about.

I also heard some unconfirmed rumours that database testing was brought a fair amount in the Best Practices tutorial. So if any of you were in that tutorial and have any

questions track me down.

After the tutorials were finished all of us from the selling source decided to go into San Francisco for some food and what not. We went to the Stinking Rose which billed

itself as a garlic resteraunt and it certaintly did not dissapoint. We hung around for a while to chit-chat and what not. It is my first time in San Francisco and it pretty much

has further confirmed that I am definately not a city guy :).

Today’s sessions are underway and thus far I have found myself working the entire time but I plan on stopping that after the current round of sessions is over. I am looking

forward to going to Give Your Site A Boost With memcached from Ben Ramsey and High Performance PHP & MySQL Scaling Techniques by Eli White. We will also be spending some time

today setting up the Selling Source booth. We are also sponsering the opening reception tonight in the exhibit hall which I don’t really think means anything other than we’ll

have our logo plastered in a few key places which is always nice. Also we are giving away a fairly nifty prize at the end of the conference to a random winner of a little code challenge that we put together.

If any of the fellow conference goers plan on going to the opening reception be sure to track me down and say hello. I think I am going to leave both my laptop and black

berry so there will be no distractions. I would love to talk to y’all about pretty much anything. :P.

Posted in PHP | Leave a comment

Going to ZendCon

I will be leaving for ZendCon on Sunday. This will be my first zend con and I am really looking forward to going. I was hoping to speak at the conference about refactoring and database testing but alas it wasn’t meant to be :). I figure it gives me more time to enjoy everyone else’s talks and I can also meet the other attendees without the impending doom of everyone in a room paying attention to me.

I will be attending the conference with a sizable group of co-workers from The Selling Source and will be spending some time in our booth in the exhibit hall. If any of you would like to discuss unit testing, late static binding, or what not please come track me down. I am very interested to talk with anyone that may have checked out the PHPUnit Database extension. I have a small list of features that I am hoping to add shortly and would love to hear about any other features people may be looking for.

Posted in PHP | 3 Comments

Late static binding….sorta :/

The good news is late static binding has been introduced into head and looks like it will be merged into 5.3 before it is released. The horrible news is I really don’t think the patch went as far as it needs to.

If you look at the original posts that cropped up about a year and a half ago the whole purpose of late static binding was to allow the same kind of flexibility provided by inheritance of standard class methods for static methods, properties, and constants. This wouldn’t really open the door for any grandios, new kind of applications, it would just allow a new way to code libraries the most prominant example being an Active Record Library.

This is now possible, however I think there is a very unfortunate limitation that I brought up a few times on the Internals mailing list to apparently no avail. The problem is with the fact that static will ALWAYS return the ‘resolved’ name of the class used to call the current function. So, imagine the following method:

class Foo
{
    //...

    static public function test()
    {
        return static::$some_property;
    }

    //...
}

class Bar extends Foo
{
}

If you call test using Foo::test() then static:: will resolve to the ‘Foo’ class. If you call it using Bar::test() then static:: will resolve to ‘Bar’. This is correct and works well for simple inheritance. However things start taking a downward turn the more you use inheritance. Consider the following change to Bar and the addition of a new class Bar_Child:

class Foo
{
    //...

    static public function test()
    {
        return static::$some_property;
    }

    //...
}

class Bar extends Foo
{
    static public function test()
    {
        // Do some work specific to Bar

        return parent::test();
    }
}

class Bar_Child extends Bar
{
}

Now, calling Foo::test() will again result in static:: being bound to ‘Foo’. However, due to the fact that parent:: will resolve to Foo:: that means the call Bar::test() will now result in static:: being bound to ‘Foo’. Bar_Child::test() will do exactly the same thing, static:: will again be bound to ‘Foo’. This is incredibly inflexible and in my opinion this is the exact problem that ‘late static binding’ is SUPPOSED to fix.

There are a couple of ways to fix this that I can think of right now, unfortunately nobody on list seems very motivated to explore any compromises. The two ways that come to mind immediately are either setting the behavior of parent:: such that it forwards the calling class through the next function call. So in the example above, calling Bar::test() will still result in calling Foo::test() however it will not ‘reset’ the calling class so that static:: will still resolve to ‘Bar::’, likewise Bar_Child::test() will result in static:: being bound to ‘Bar_Child’.

The second alternative is introducing another scope. I have no clue what this scope would be called, but it would basically implement the functionality I just described for parent:: above but would do it using a new keyword so parent:: could remain the same.

Dmitry Stogov mentioned my first alternative on the list however he also included this functionality for the self:: scope which I could see causing some serious problems. In either case, I am thankful that the functionality has started to make its way in, but I can’t help but think that myself and some other early proponents of the functionality are getting completely shafted.

Posted in PHP | 4 Comments

Adding Database Tests to Existing PHPUnit Test Cases

When I was first creating the Database Extension for PHPUnit I realized that there was a very high likelihood that several people would have tests that were already written that they would like to add additional database tests too. To accomplish this I actually wrote the PHPUnit_Extensions_Database_DefaultTester class. In fact, if you were to look at the source of the database test case you will see that all of it’s operations are actually forwarded to this class which does all of the work.

Please continue reading to see how you can use composition to add database tests to your existing test cases.

Continue reading

Posted in PHP Testing | 9 Comments

PHPUnit Database Extension (DBUnit Port)

I have completed the initial feature set for the Database extension to PHPUnit. This is a essentially a port of DBUnit to PHP.

For those that may not have read any of my previous postings on the subject the goal of this software is to extend the functionality of PHPUnit to allow using seed data to put a given database into a known state prior to executing each test. It also provides an easy mechanism to compare database contents with an expected dataset.

The database extension has recently been merged into the PHPUnit 3.2 branch and is scheduled to be released in that version. Sebastian Bergmann will be introducing the extension in his Advanced Testing with PHPUnit talk at PHP|Works 2007 in Atlanta September 13 – 14. If you would like to tinker around with the database extension prior to it’s release you can always download the latest copy of PHPUnit 3.2 from svn: svn://svn.phpunit.de/phpunit/phpunit/branches/3.2. The source can also be browsed at http://www.phpunit.de/browser/phpunit/branches/3.2/PHPUnit/Extensions/Database.

Please continue reading for an example of how you can now use PHPUnit to even more effectively test data-centric applications.

Continue reading

Posted in PHP Testing | 35 Comments