Die Flagge des Marasek



Aktuell Texte Der Comic Impressum Kalender Suche PHP-Klassen Container-Wizard main.s21


Religion & Philosophie

Reshaping PHP

Vorheriger: Apple Computer wird zu AppleNächster: Köstlich
Eingeordnet in: Foreign Language, Programmieren

I found an interesting website of a guy named Tony Marston. He wrote an article about how the PHP developers should not let themselves be talked into turning PHP into another Ruby, Python or Java, breaking backwards compatibility in the process. He especially lambasts breaking backwards compatibility and advises those who whish PHP to behave like different languages to just stick to those.

He's got a point, however, those demanding changes in PHP have got a point either, so I say, because I myself whish for some changes.

PHP has distinct PHP problems, which stem from the fact that PHP is a grown language as opposed to languages that were meticulously designed on a drawing table with a certain goal in mind, such as Java.
That is something which I love and hate about PHP. First, because PHP is so damn flexible. No "everything must be an object" crap or "we push our approach down your throat". As much as I came to like to do full blown OO programming, spending time to draft classes and how they will talk to each other to perform Maraseks Dance of Happy Classes, I like to open up an editor and code right away, just to test something. Often, I go the other way round: first, I start programming, changing, tweaking, and then, when I have a feeling to where I am headed, I start to atomize my functionality in slim classes. I have a rather intuitive approach to programming, and PHP suits me exceedingly well, as it never comes between me and my creativity.
However, as said above, I also have a meticulous side, which gets mad at PHP whenever that language makes something I did not expect any sane person would even take into consideration, like its awful treatment of types.

Now what would I desire as changes?

  • Namespaces
    This is quite obvious, even more since the PHP team took the same name for a class as I did. Yuck.
  • Type Hinting
    To hint types when declaring a function is terribly useful. This even pushed me more into using objects, as I can hint towards objects or arrays. Unfortunately, I cannot hint towards the other types, which would save me a lot of tedious work checking it myself and triggering errors.
  • Better Type handling
    Now this one is critical, as it breaks backwards compatibility. I really, really hate that PHP treats 0 the same way as FALSE, NULL, empty() and "". Zero is quite a valid number, having 0 € on my account is a statement, while NULL means: I don't know. That is a difference.
  • Strong Types
    Baaaaaaad. By now, I would really like to have strong types. Not per default, but as an option. Or that implicit type conversion with loss of information - like $string = "foo", $string++ would at least throw an E_NOTICE.

Breaking backwards compatibility is evil, but not doing it might be more evil, especially with PHP and its long track of security related issues. One should have never programmed with superglobals to begin with, so breaking them does not break my heart. As said before, the special situation of PHP is that the language is grown, and sometimes growth leads into a wrong direction.

Apart from that, I thought about why so many people desire changes in PHP and why "keep to your languages" isn't an option for them.

The problem is that you get PHP and MySQL around every corner. Everyone desires that you do stuff in PHP and MySQL for them. I don't whant to know how frustrating it must feel if you're accustomed to Java and then have to work in PHP 4.1.1 - you will scream for features. I had the same experience when I came back from PostgreSQL 8 to MySQL 4.1 and that puny little piece of crap was not able to do me a subquery or even do a simple join with USING (key). But I had to make this project in exactly that and PostgreSQL was out of reach, so I spend most of the time writing around MySQLs limitations.

Regarding PHP, I think the most proper way to shape future development is to make good use of E_NOTICE and E_STRICT as well as adding new features without breaking backwards compatibility. However, BWC is no God, and sometimes a clean cut is better than long suffering.


Bitte beachten: Kommentare sind nicht sofort sichtbar, sondern werden erst nach einer kurzen Prüfung freigegeben, sofern keine rechtliche Beanstandung vorliegt.
Rechtlich bedenkliche Inhalte werden entweder entschärft oder nicht veröffentlicht.

* Titel  
* Nickname  
* Kommentar