Php++, and why Rails isn’t for me

April 1st, 2007 in Php

Here’s an idea that I haven’t had a chance to hack at yet: Php++. Take the base language, clean it up using a simple pre-processor, and spit out regular Php. Think of it like Rails, but inverted. Instead of creating a few mini-languages to replace HTML/CSS/Javascript/SQL generation, find a way to string these languages together in a cleaner way. An exoskeleton versus an endoskeleton.

I don’t have anything against Ruby (it’s a cleaner, crisper Perl), and it’s not like I don’t appreciate what Rails tries to do. What gets in my way is that Rails introduces new domain-specific-languages that aren’t as good as what they replace.

What Rail’s DSLs intend to do is great: automating database migrations, schema/code synchronization, managing project skeletons, Javascript integration, and more. The problem is that these DSLs are specific to Rails, and represent non-portable knowledge. You have to relearn how to do JOINs, UNIONs, and POSTS. Not that the Rails way isn’t clever, but it’s a layer between a set of languages that are already really good. My question is, what’s wrong with writing SQL, HTML, and JS? I think the answer is that their intersection is messy, and you duplicate your application’s domain knowledge between each of the specific languages.

So Rails helps to enforce the One Definition Rule, but it does so by inventing new mini-languages. Rails does it well, which is forgivable, but I’m thinking that the same end is possible while still embracing SQL, HTML, and Javascript. Anything you know about these languages should still apply, so anything you learn using the tool would be useful elsewhere.

Enter Php++

Add a small number of keywords similar to the QT C++ extensions that make it easy to generate sensible code from your SQL/HTML/JS. For example:

class student {
    public get address() = "SELECT * FROM Students WHERE id = '$sid'";
    public set address($street, $number, $etc) = "INSERT ...";

    // The display portions rely on get/set
    public edit show_edit_form() default(); 
    public edit show_inline_edit() default(ajax);
    public view display_full_address() default(); 

}

The extensions would also take care of the mess around escaping SQL, and could switch between various SQL backends without much trouble (mysql_*, Pear::DB, etc.). And the Php++ processor would do the right thing, and would generate real, readable Php.

Now my only problem is finding the time to hack at it.