I like all of my model classes to have a created_at and an updated_at timestamp that automatically do the correct thing to provide a very basic audit trail. This does not let you off the hook for doing actual auditing, but it is a nice way to do sanity checks and get some instant information about records. fActiveRecord makes this pretty easy to do, let’s dive into some code.

class someModel extends fActiveRecord {
  /**
   * The fActiveRecord class provides the configure function to let you set-up Active Record hooks.  Let's do that now
   */
  protected function configure() {
    fORMDate::configureDateCreatedColumn($this, 'created_at');
    fORMDate::configureDateUpdatedColumn($this, 'updated_at');
  }
}

Easy as that you now have your created_ats and updated_ats working great for the someModel class. Here’s the cool part though, because boilerplate code is stupid ugly code, if you want to use this across your project simply do the following.

class ActiveRecord extends fActiveRecord {
  /**
   * For this project every model should record created_at and updated_at
   */
  protected function configure() {
    fORMDate::configureDateCreatedColumn($this, 'created_at');
    fORMDate::configureDateUpdatedColumn($this, 'updated_at');
  }
}

Now when you need to create a new model simply extend ActiveRecord instead of fActiveRecord and auto timestamps are done.

that's a pretty sweet logo

On June 3rd I typed the following into my Terminal.

mkdir faveroo
cd faveroo
git init

On August 15th I typed the following into my Terminal.

cd ~/src/faveroo
php deploy.php production

Then I watched and held my breath as my carefully crafted deployment script worked its way through 2 months of code and pushed them across the line. Then I fired up my browser and went to http://faveroo.com and waited for the now familiar homepage to show up… I’m sure it took less than a second to load, but it seemed like an eternity, finally it was up. I worked for the next few hours exercising the application through all its various operations, squishing little bugs here and there that popped up from being in a different environment. Two months of development, and finally it was live, and it actually worked. A few hours later we started hooking up people with sweet deals and putting money in the bank, mission accomplished.

Faveroo.com is my first project at my new job at 614 Media Group. It was a skunkworks project up through the end of July, so I couldn’t come to this blog and talk about it. I did all of the coding for Faveroo and my colleague Jeff Guciardo did all the design work to make it look so pretty (it’s probably the prettiest thing I’ve ever had the opportunity to create). The basic premise of the website is that our team of dedicated sales people go and find great local deals, then we throw them up on Faveroo.com, and then we help people save some cash. When you buy a Faveroo you save some money, the business makes money, we make money, and 3% of the sale automatically goes to charity, it’s win-win-win-win. But I’m neither marketing nor sales, so I will stick with what I know and what I knows is tech, so let’s talk about that for a minute.

Faveroo is a PHP website that includes the public frontend, a private backend, and a series of maintenance scripts that make sure everything works like clockwork. When I was starting up the Faveroo project I was given carte blanche as to how to build it. All of our other web properties use the classic LAMP stack, so to keep operations fairly sane and because I deeply love PHP, I decided to build out Faveroo on a classic LAMP stack as well. The code is Object Oriented, nearly MVC, PHP 5.2 code. I looked around, had been for a long time, at various PHP Web Frameworks. I had just come off of working with rails on a side project and so I knew the joy and frustration of work with a framework.

As you may be aware, I’m crazy in love with Flourish and decided that I would use it as a major component. I have been a fan of Flourish for a while now, probably over a year, but this was the first big application I was going to use it on, and really the first large scale from scratch application I have ever written. Now don’t get me wrong, I’m no rookie to this slinging code stuff, I’ve maintained huge legacy applications, built middle-ware up from nothing, and even rewritten large applications to the point that almost all of the original code has been replaced. But this would be the first time that if I didn’t like something in my code, it was because I was the stupid jack-ass that made such a boneheaded decision. Well, not the first time, but the first time I couldn’t easily blame someone else

I want to say that the decision to go with Flourish is probably what made the rapid turn around time possible. It’s a wonderful library that helps you do things right but doesn’t force you to do anything you don’t need. The thing that amazed me as I used it is I started off only wanting to pull bits and pieces, maybe some fCryptography here and a little fMessaging there, but as I got familiar (and boy howdy did I get familiar) with the docs, I just found more and more amazing functionality and a beautifully coherent system. Flourish was clearly written to be used, and by the end of the project I found I was using almost every class. It’s clearly a tool written for real world use from real world experience.

Flourish and jQuery are really the 2 big external dependencies for Faveroo, the rest of the code was written by me. I found this minimal system worked very well for me. I wrote a router in about 100 lines of PHP code, it’s nothing earth shattering but I think it has a few novel ideas. I’ve since built a new version of this router that is shorter and has less complex code paths. At some point in the future I may try to make a more generic version of this router and release it open source. All of the model classes are fairly straightforward using the excellent fActiveRecord as a base.

I spent about a week spinning up my minimalist framework, but it paid off big. I knew how the system worked every step of the way, and more importantly, I could alter it in minor ways to achieve dramatic results. All of this is possible with established frameworks, but here I got away without having to climb up a learning curve. This gave me more time to understand the problem domain and to learn how to best use Flourish.

With this experience under my belt I’m looking forward to continuing to learn, and hopefully to contribute back to, Flourish and PHP development in general. This project has shown me that in 2 months I can go from nothing to cash hitting the bank account. I feel reinvigorated to make cool things that add value to people’s lives and reassured of my abilities as a programmer. After a long period feeling burned out and wasted, I remember why I love programming, and why I love creating, and why this is the only thing I can ever see myself doing.

Flourish's sweet logo

Looks like my claim of writing fast and furious didn’t come to pass, oh well. For the last few weeks I’ve been working on a hush hush project for work. It’s not done yet but we are nearing the end of the road for the MVP to be released soon. I wanted to write a quick update to discuss what it’s been like getting back on my developer feet after burning out.

First off I’m engaged in my work again. For months I had felt disconnected, on autopilot, just trying to get through the day and hit some milestones. Secondly, I enjoyed playing cowboy for a while but have cone to realize that not all the habits I picked up in Corporate America were bad. Thirdly, I’m back to getting serious amounts of work done and am solving interesting problems.

Enough touchy feely hippie bullshit, let’s get down to some business. I’ve been building a largish scale php application for the last couple of weeks and I wanted to reflect on the process.

I started off looking at various php frameworks a few weeks before starting this new project. I had kept an ear to the ground in the php framework area since forever so I knew the big players. I had also dabbled in some ruby on rails so I knew the bliss of when a framework gets it right, and the frustration of running up against something you would have done differently.

I looked into several frameworks CakePHP, Symfony, Zend Framework, Fat Free PHP, Yii, Noloh, and Recess! to name a few. They were all quite interesting but they all felt oddly foreign. Imagine if ruby on rails came out and it was a port of .Net web forms for ruby, blech. All the frameworks I looked at felt like they were trying to pave over PHP and make it into ruby lite or .Net lite. Each one was well put together on the whole and with some effort I’m sure I could have become proficient in any of them. Then I remembered an old friend I had played with before, Will Bond’s unframework Flourish.

If you haven’t taken a look before I urge you to do so now. Flourish is exactly what PHP needs, a strong core of classes geared toward common web tasks, with an eye towards simplicity, security, and consistency. After having used Flourish for a few weeks I can do nothing but sing its praises. Let me say that working with the combination of Flourish + PHP is a completely different experience than just writing PHP. Flourish gives you a sane construct around which you can build high quality applications. Here’s a list of things Flourish provides:

• Cross Database support for DB2, MSSQL, MySQL, Oracle, PostgreSQL, and SQLite
• An extremely good ActiveRecord implementation
• Filesystem with psuedo-transactions
• Safe consistent handling of Requests
• Session handling with special resources for Authentication
• Classes for creating HTML including a quality Templating mechanism
• Great Utility classes (think ActiveRecord rails people)
• Amazing Email support
• Classes for handling Dates, Numbers, and Money
• High quality Exceptions and Handling Facilities

The thing that you will notice with Flourish is that it’s a library that’s seen real world use. It provides a high quality core but understands that it shouldn’t try to be everything to everyone. The components interoperate nicely but you also function in isolation quite capably. It truly hits all the high points you would want from a library, but there is even more.

DOCUMENTATION: The Flourish documentation is some of the best I’ve ever seen. There is full PHPDoc for every class, which is nice, but more importantly there is “Class Documentation” that explains how the class is intended to be used, with code examples to get you started. The documentation is written very well and is incredibly in-depth. You could sit down and read it like a book, it’s that good.

COMMUNITY: The Flourish discussion boards are active and I have never seen a posting go unanswered. Will Bond himself usually answers within a few hours of your posting, I know he has more than once helped me fix some tricky bug or better explained how something worked to me. The ability to reach out and communicate with the author is amazing, it also makes you want to provide support for the project.

CONSISTENCY: The Flourish API is amazingly consistent. I keep finding myself saying, “That’s how I would have written it” while using it. If you learn how fCookie works, you know how fSession works, and you even know how fRequest works. Flourish simplifies things to the point that it’s worth it to go the extra mile to add a bit of security to your code, because it makes it dead simple. Then you look back and realize that it also has helped you write self-documenting code, and jesus, did it just fucking cut my lawn too, what the hell?

SECURITY: As I alluded to earlier, Flourish encourages writing secure code. Flourish takes security seriously enough to have an entire compendium on just that topic and how it relates to PHP. My code is definitely more secure now that I use Flourish, from better security in parsing Request variables, to easily preventing Cross Site Request Forgeries, Flourish has you covered.

Ok, so I didn’t really expect this to turn into a huge love fest about how much I love Flourish but that’s where we are at. I want to over the course of a few blog posts really explore Flourish. I haven’t fully figured out what format these are going to take, but if you are a PHP developer who wants to take their code to the next level, stay tuned.

Freedom has never kicked so much ass

I wrote yesterday about the importance of open source software. I got one comment saying that prosper would be awesome if it were in the public domain. Here is the comment from Arto Bendiken

Prosper looks *sweet*. It’d be awesome if Prosper indeed were in the public domain. I think such a move would make for a decisive selling point over the numerous competing PHP libraries, setting Prosper clearly apart from the herd and allowing it to be easily embedded into any new emerging PHP web frameworks.

It’s worth mentioning that a key reason that SQLite, which is in the public domain, has prospered (no pun intended) has been the fact that it can be so easily (both technically and legally speaking) embedded into any other software. The end results of technical excellence combined with singularly liberal licensing speak for themselves: http://www.sqlite.org/famous.html

I think a lot of these same benefits could come into play also in such a potentially key higher-level web app infrastructure piece as Prosper. It certainly seems that you have the technical side of things well in hand, already, so here’s hoping for a bright and prosperous future.

Well I completely agree with Arto and want to clear up any confusion about prosper and its license. Prosper was original hosted on Google Code, which requires you to choose a license, at the time I selected the MIT/X11 license based off of my belief that it was the most free. A little further down the road I saw the WTFPL – Do What The Fuck You Want To Public License and thought about switching to that. There is a bluntness to the ideal of that license that appealed to me.

The problem with the WTFPL is of course its name, I want prosper to power lots of things and that means taking into account a wider audience. While hackers and rock star programmers can easily adopt something with WTFPL, I didn’t want to be responsible for some corporation turning their back on an otherwise useful library because they were squeamish about a word in the license.

I always thought people just hated the letter C... then I found out this means no copyright

Then I found this post on Hacker News (ironically by the same Arto Bendiken) and it lead me to the Unlicense. The Unlicense is exactly what I was looking for and simple to adopt. If you go to the GitHub repo you will see that the project is now officially Unlicense’d. The 0.8 release will be the first official Unlicense’d release, and so will every release going forward. I believe in free and open source software and so I’m publicly declaring now that prosper will always be free, open source, and unencumbered. The mechanism that I will use to ensure this going forward will be Unlicense.

What’s the big deal, plenty of things are open source, why is this any different? The difference is that I’m giving this away fully, without any restrictions. Want to build a cool new library that uses prosper as the low-level database abstraction layer, go for it. Want to build a proprietary ORM that utilizes prosper, go for it. Want to repackage prosper and try to sell it (as underhanded as that is), go for it. Want to smother prosper with jam and eat it, if you can find a way to, go for it. Want to…. enough already, you can do whatever you like.

It is easy to talk about things like freedom and support them in the abstract, it becomes more difficult when you have something concrete. People could very well take prosper and take it in directions I don’t care to see it go, but that is life, that is creation, that is the essence of open source. It is my goal to see prosper provide a solid foundation for building new and better tools and frameworks in php. I want as many people as possible to use it, and so this was a logical choice.

The next time you have some useful chunk of code lying around and you want to give it to the public domain for the good of the public, think about using Unlicense. I can’t say it any better than they can so I will just quote their section about why you should use Unlicense. “Because you have more important things to do than enriching lawyers or imposing petty restrictions on users of your code.”

I want you to come to Matt's CodeMash Session

Disclaimer: This post is shameless, and I mean really, really shameless, self-promotion.

If you have ever been on this site before you may recognize the name prosper. Prosper is my attempt at creating something of value for the PHP community. For anyone is following along at GitHub, you may have noticed that there hasn’t been much work done in the last few weeks, what’s the deal?! Well, don’t fret, prosper is still under active development but it has been frozen for a few reasons.

1. It was the holidays, and I was doing this weird thing where you interact with humans
2. I’ve been seeking, and receiving, feedback from some key users
3. I will be giving a live demo of Prosper and have been working on that demo more than the library as of late

“A Live Demo?” you say bedeviled by the notion. Don’t worry you don’t all need to cram into my apartment to see some technological wizardry, all you need to do is head on over to CodeMash, then at 3:00 on Thursday head to room E. The awesome company that I work for, HMB is sponsoring CodeMash and have selected me to give a presentation on this crazy open source project they’ve heard I wrote.

I’ve been working on a very minimal PowerPoint, because I know people can read so there is no point in me reading to them. At the end of the presentation though will be a live demo building up a simple database backed PHP application for managing all the fond memories of CodeMash, a quote board. In case you are unaware, building an application in front of people is incredibly nerve-wracking, which is why for the next 5 days I will be building this application over and over while talking to absolutely no one, to the confusion of my poor neighbors.

Live demos have a fantastic way of just going all wrong, as Bill will demonstrate

I’m not trying to poke fun at Mr. Gates (for once), giving a presentation in front of people, with new software is never a fun experience, and bad things© do happen. I will be practicing and practicing and practicing, and after that I will probably be practicing, for this presentation to make it the best it can be.

In other prosper news, I have set up http://prosper-lib.com to be the new home of prosper (currently just a forward to here, although the update is still working its way through GoDaddy’s intertubes so you may get a parking page for a while). I am working with my good friend Ashley Kruso to get a new logo for prosper. Once I have the new logo I will begin building a new web home for prosper that will be all kinds of pretty. This is all in the run-up to Prosper 1.0, which is a goal for this year, but I haven’t quite nailed down when.

It’s all steam ahead on Prosper, thanks to the contributions and support of many people. When I started this project a few months ago I would not have been able to guess what it would turn into, so thanks to everyone that has helped or is going to help. By month’s end there should be a 0.8 release that will have all kinds of new fun stuff including deferred result sets and lots of bug fixes from my friend who was kind enough to evaluate Prosper, Ian.

open source software, the gift for everyone!

There is an early Christmas present for anyone using prosper, a new release, Version 0.7! You can get it hot off the GitHub or download here.

Version 0.7 has a lot of exciting new features, the biggest 2 were spurred on by Ian Potter and Jeremiah Peschka. The phpDoc has been updated (if you are still using version 0.6 you can find the old documentation here). The big news is that prosper uses Prepared Statements by default now, gracefully and transparently falling back to string interpolation where Prepared Statements are not available. The second new feature is the introduction of Explicit Transaction Management.

try {
  Prosper\Query::begin();

  //Do a bunch of stuff

  Prosper\Query::commit();
} catch (Exception $e) {
  Prosper\Query::rollback();
}

Only some of the adapters support this, the ones that do not simply ignore the call to begin(), commit(), and rollback(). You can use the has_transactions() functions to check if the current adapter supports transactions.

Happy Holidays, and Happy Coding!

you can find really cool images searching for impedance mismatch, this one has lazers (with a z)

There is a threat to good software, one that threatens the most promising of software projects. This threat is impedance mismatch. I use impedence mismatch in the sense that Object-relational impedance mismatch uses the term, but make no mistake, I’m not talking about the difficulties of writing an ORM. What I wish to discuss is far more insidious, it is death by a thousand paper cuts, it can spell ruin for any project. Impedance mismatch is born out of the confusing first steps of a project, it can also arise from multiple developers working over time on a large project or from internal disagreements over the optimal solution.

The major problem is that when we go about designing some new piece of software, some whiz-bang solution, we do not fully understand the problem domain. Any good development team will spend days filling up whiteboards with the solution that models the problem domain, but anyone with experience will tell you that once you get into the guts of a problem you realize that things need to be changed. This is fine, in fact this is a sign that you are solving the actual problem and not the ideal one you began with, don’t worry about changing your solution to meet the realities of the domain. The problem though is making these changes first class citizens and not some weird third class monster thrown into the mix.

Have you ever been on a project and heard a conversation like this?

New Developer: What is X?
Grizzled Veteran: X is what we refer to internally as Y
New Developer: Why do we call it Y internally but X on the UI
Grizzled Veteran: Time constraints… budgets…. other misc. bullshit
New Developer: *mental note: X is called Y sometimes*

BAMMO! There’s some nasty impedance mismatch there. The problem is not so much in what we display to the user, or what our object properties are called, or what the database columns are named, the issue is that we have made our mental model convoluted. At the heart of all these systems we build as software developers is some sort of mental model, at runtime this is expressed in system as an object graph, for persistence it is expressed as a collection of tables and relationships, but all of these things are just a representation of some mental model.

artist depiction: working with an elegant mental model

When our mental model is internally consistent and simple and elegant, it makes life easy and happy and unicorns shoot out of our monitors and everything is sunshine and puppies. When your mental model gets convoluted it can be an awful and bewildering experience. The problem comes from an increased overhead, instead of the mapping from one representation to the next being clear-cut, the developer has to carry around a hashmap in their skull mapping various representations of their mental model. The difficulty of carrying out even trivial tasks is increased as the mapping from X -> Y -> Z -> Q -> P takes place.

impedance mismatch vs. coupling: battle to the death

So let’s just name everything the same and go home, problem solved. Oh, if it could only be so easy, the problem is that on the other end from impedance mismatch is a devilish little troll named coupling. Coupling is the amount that two pieces of software are intertwined, they could be tightly-coupled wherein changing one requires changing the other, or they can be loosely-coupled all the way to the point of being considered decoupled or orthogonal. Orthogonal pieces are nice to work with because you can change one and know that you won’t have side-effects on other pieces. Orthogonality goes by some other names: encapsulation, modularity, and decoupled, it is generally considered a Good Thing© and I make no argument against it.

We now have these two seemingly opposing forces, we want to decrease impedance mismatch without introducing coupling, what should we do? There are many ways to deal with this issue, let’s look at a few.

Adapters are nice little pieces of code (also called wrappers), that allow two different things to look the same. Let’s assume we want to write some code to manage users, users have a name, an address, and an age. The developer of the class decides that this object can be pretty simple.

class User {
  public $name;
  public $address;
  public $age;
}

The database developer decides that he loves structured data and that this should be broken out into all kinds of columns and tables.

table user (
  user_id int autoincrement primary key,
  first_name varchar,
  last_name varchar,
  addr_street varchar,
  addr_number int,
  addr_city int foreign key,
  addr_zipcode int,
  age int
)

table city (
  city_id int autoincrement primary key,
  city_name varchar,
  state_id int foreign key,
)

table state (
  state_id int autoincrement primary key,
  state_name varchar,
  state_abbrev varchar
)

We could create an adapter class that bridges the difference, for brevity’s sake I won’t include the code for it, but it would basically translate strings into database fields, as the application developer I get to imagine the database as mirroring my object, even though it doesn’t.

ORM – ORM’s are like automatic adapters. They are not without their faults and some implementations are better than others, but they mask the complexity of marshaling data and reduce the impedance mismatch.

Convention over Configuration – This was made famous by Ruby on Rails. There is some strong convention that you follow that allows for a consistent mapping between domains, an example would be that tables are always named the pluralized version of the class name.

There is no silver bullet to solving the problem of impedance mismatch, but a combination of the above can help limit it. The best thing you can do is be aware of the problem, don’t introduce impedance where it is unnecessary, and never be afraid to ruthlessly refactor out impedance mismatch when you find it. Keeping impedance mismatch low increases developer productivity, lowers the bar for bringing on new people, and makes unicorns leap out of your monitor farting rainbows.

don't worry, no babies were harmed

Yesterday my friend Ian sent me a tweet about prosper

@ihumanable I’d be more interested in using Prosper if it provided support for true prepared statements instead of concatenating strings.
6:29 AM Dec 7th – pian0

With that my baby was born, the baby was a version of prosper that utilized prepared statements where appropriate. Prosper’s main functionality has been coded for a while and the bulk of the work I’ve been doing as of late has been testing, improving backend support, and adding new functionality. The nice thing about this kind of work is that you don’t have to go mucking around in working code, you are just fixing broken stuff and adding new functionality. The idea of adding prepared statements made me a little queasy, I had briefly looked at it when I was starting prosper but decided that they were so varied that for the first attempt I would just avoid the headache. What’s the problem you ask, let’s take a look at this feature table real quick.

As you can see the support for prepared statements varies in the Vendor Specific Database Extensions of php. There is also the fact that prepared statement support is poorly implemented in several extensions, they can be coded around but it adds a good deal of complexity. Despite all the reasons not to implement prepared statements, safety, speed, and correctness dictate that I should at least give it a go.

Yesterday and today were my go, and I met with some success. Prepared statements are not all that difficult to implement for a given backend, throw in some question marks, call the correct bind function, and you’re off and running. The real difficulty is the cross-platform nature of prosper. I wanted prepared statements to be a first class citizen, I didn’t want to decrease any existing functionality, I wanted to not overly complicate the way prosper works, and because there are 11 adapters that need to be upgraded, I wanted it to be simple to add this functionality to a given adapter.

I worked and toiled and toiled and worked, I tried hacking something up to make the MySQL adapter work, ran into the bind_results function and screamed at it for a while. Then I got out some paper and drew out some diagrams, thought about sample code. Then I went to sleep. Then I woke up and in the shower pondered the proper syntax for passing around typing information and the division of labor for transformation. Then I hacked on it some more and wrote a quick test. Then and this is the most important part I realized I had done it absolutely backwards.

I had some clues that stuff wasn’t working out right, I hit a point where I would either need to embed an if statement in every function of an adapter or have a duplicate function. I thought that with some clever coding I could shove this down into the base class, it wasn’t great but it was working. Then I saw another red flag when I realized that the processing in the where clause was identical to the processing in the values clause, and I applied some refactoring. This is when I realized that there was a single function that I could have modified and had the whole thing work much more elegantly.

That is when I had to come to the decision to murder my baby. I had painstakingly worked out the kinks for two days, traveling far down this road, touching a bunch of code, and now I realize the best way forward is back. The best thing I can do right now is to revert my changes to Monday morning and lose 2 days of work, and that is great!

It’s not the best outcome, in an ideal world I would have seen this solution before and applied it and not wasted 2 days. The thing is that I’ve learned a great deal, I’ve come up with a much better implementation, and I’ve been reminded of an important lesson, never be afraid to throw away code. The code I wrote is adequate, it works well enough, but it is far from optimal. I could keep going, head down, plowing away making as many problems as I solve trying to build a house on an unsound foundation. The point here is to pay attention to those red flags.

The other important point is that sometimes you have to actually try something to find the thing that will work. You may lose some time, but even after sitting down with pencil and paper, thinking long and hard, the optimal path didn’t come to me until I walked down the wrong road. That’s just life sometimes as a software developer, you have to learn to live with it.

I will continue working on prepared statements for prosper, and I hope that by 0.7 or 0.8 they will be implemented and in there. I still question the syntax and think that I can clean it up, right now the plan is for prosper to support unnamed parameters (?), named parameters (:name), unnamed typed parameters (%i), and named typed parameters (:name%s), but all this seems like a little much. Good thing prosper hasn’t had a 1.0 release yet

he never forgets, even the stupid decisions

I am a fan of php, ever since my first software development job where I was thrown in the deep end and had to sink or swim. I swam in the sea of php and actually think it is a very nice language (begin receiving hate mail…. now!). You see, I never knew the non-OOP php, I was brought into a well managed project with Classes and Interfaces, it was basically Java with dollar-sigils thrown in. I never suffered through the spaghetti nightmare that so much php is, so I’m admittedly wearing some rose-colored glasses.

There is one feature that I love about php, it is the height of elegance, the associative array. The associative array can do anything, need a stack just use array_push and array_pop, need to do some functional programming array_map, array_filter, and array_walk are your friends. The beauty of the associative array in php is that it is ubiquitous, its a hash map, array, stack, object, all rolled into one.

The problem with the associative array though is that its create syntax is ugly. Here is how you create an array in php

$example = array(1, 2, 3);

That doesn’t seem so bad, what am I complaining about, well the problem comes when you have nested arrays (which is somewhat common).

$configuration =
array(
  'name' => 'My Configuration',
  'server' => array (
    'name' => 'localhost',
    'port' => '8080',
    'users' => array (
      array (
        'username' => 'example',
        'password' => 'example'
      ),
      array (
        'username' => 'user01',
        'password' => 'pass01'
      )
    ),
    'overrides' => array (
      'https' => false )
  )
);

The biggest problem is not that I have to keep writing the word array its that arrays don’t look like arrays. They look like function calls, with other nested function calls, of course the newlines and tabs help out, but they don’t solve the problem. Let’s look at how this would appear in JavaScript using super-awesome JSON.

var configuration = {
  name: 'My Configuration',
  server: {
    name: 'localhost',
    port: '8080',
    users: [ {username: 'example', password: 'example'},
             {username: 'user01', password: 'pass01'} ],
    overrides: {https: false}
  }
};

That’s much nicer and the more important part is that hashes look like hashes and arrays look like arrays. There was a proposed php syntax change that was discussed to death and an analysis here which would have made the following legal php

$configuration = [
  'name' => 'My Configuration',
  'server' => [
    'name' => 'localhost',
    'port' => '8080',
    'users' => [ ['username' => 'example', 'password' => 'example'],
               ['username' => 'user01', 'password' => 'pass01'] ],
    'overrides' => ['https' => false]
  ]
];

But this is not the case, and more importantly, may never be the case. The issue has been brought up and rejected several times, with the following reasoning

I see no advantages here, only another way to do already possible thing and yet another way to confuse people.

- Anthony Dovgal

For the record: I’m -1. array() is enough. Ridiculous idea to begin with.

- Jani Taskinen

There is no reason to add another syntax for *exactly* the same thing, especially because it’s ungoogable

- Derick Rethans

Then there is this

I’m ok with it as well. Like I said over a year ago (*), it is a syntax very familiar to web developers and it feels natural to most people.

(*) http://marc.info/?l=php-internals&m=117060700805108&w=2
- Rasmus Lerdorf (the guy who created PHP)

The problem I see here is that the vote finally breaks down to 1 / 3 contributors in favor and 17 / 20 users in favor, it was then rejected. There is no recourse and as long as the people maintaining php see this as a useless feature, as a “backward incompatible syntax that duplicates already existing one, but 5 characters shorter” change request, it will never move forward.

This is a shame and it is myopic and dishonest. To trivialize this change supported by the vast majority of the php users voting as some sort of luxury people want so that they can avoid typing 5 characters is intellectually dishonest. The major point is that square brackets mean arrays in php, unless you are creating one, then it looks like a function.

$array = array(0, 1, 2, 3, 4, 5, 6); //Create the array
$element = $array[5]; //Get the element at index 5
$array[3] = "hello"; //Set the element at index 3
$array[]  = "example"; //Push an element onto the array

The dishonest part about the argument against the change is that it would be some sort of crazy zany backwards incompatible change and we would never break backwards compatibility. First off, if you are going to classify any addition to the language as backwards incompatible, then stop having a core development team, you are done, close up shop you can’t add anything to the language anymore. Secondly, php has a history of removing and adding things that break older code, anyone remember the first stab at classes, or ever written $stringvar{4} to access a character, that is going away and you should write $stringvar[4] from now on. It’s deprecated as of php 5.3.0 and will most likely be removed as of php 6.

But we are left as a community without recourse, the array function to create an array exists and by that fact alone it will remain forever. The most disheartening thing about the whole misadventure is that because this has been brought up and rejected so many times any time it is brought up now it is automatically rejected as being rejected before. Discussion has attached to this idea a Scarlett Letter, most undeservedly.

At the end of the day I won’t jump ship, but it’s one of those things that makes you stop and scratch your head. Why be so against it? I don’t buy the arguments against it, I don’t understand the fervor that the devs fight against it with, and I don’t see the harm.

As people push the boundaries of what the language can do and the concept of the DSL (pushed by those ruby people) becomes more and more prominent, language cruft will have to fall by the wayside. Not improving array literal syntax is not the end of the world, but the attitudes and egos on display fighting a harmless change that the user base wants could be.

prosper

I plan to have another real post later today, just wanted to announce a point release for the prosper library. Prosper development has been moving along and I am happy to announce that I just slapped the finishing touches on version 0.6.

Here is the 10 cent tour of the new stuff

• Changed the configuration system to take constants instead of string literals
• Added support for the older mysql library in addition to the mysqli library
• Refactored adapters internally for more concise and logical class layout
• Moved project to GitHub
• Adapters are lazy loading now, this allows the configuration to be done with minimal overhead. This functionality also allows for unit testing
• Added phpDoc Documentation to the project
• Added GitHub frontpage documentation and project roadmap

There is a new download available on GitHub that contains all the documentation and source code. Since prosper is still in the 0.* stage it may be best to just clone or fork the source, a look at the 0.7 roadmap shows that there is still a bunch of work to be done.

If you want to help there are several ways that you can provide support

• Use prosper and submit issues
• Join the project*
• Give me some feedback*

If you want to join up or give me feedback just send an email to ihumanable@gmail.com with prosper in the subject line