【拓展閱讀】
PHP語言最令人“抓狂”的特性
轉換令人頭痛
在利用PHP進行專案建立的過程中，最大的挑戰之一在於牢記我們哪些時候需要輸入HTML、而哪些時代需要輸入PHP程式碼。將二者相結合正是PHP語言的一大賣點，但要充分發揮其優勢卻著實不是易事。當我們檢視某個檔案並關注其中的程式碼時，首先需要搞清楚的就是—那些迫使我們不得不從HTML編寫轉向建立服務器指令的標籤都在哪裡?各位必須要高度重視這些標籤，因為只有這樣我們才能將程式碼與標記整合起來並使其順暢運作。當然，大多數情況下它只會讓人暈頭轉向。
標記的迷宮
將伺服器指令與瀏覽器標記結合起來實在是一種失誤。在Java這方面，其研發團隊嚴格遵循著MVC模式。資料模型被歸於一個檔案中，用於控制檢視的佈局結構被歸於另外的檔案中，而用於構建控制器的邏輯也擁有自己的`歸屬檔案。將這些條目區分並隔離開來能夠讓整個專案變得更有條理。但在PHP方面，最基本的設計思路就是開發者應當將HTML標記與伺服器的控制器邏輯雜糅在一起。雖然我們不是沒辦法把它們區分開—大多數人也確實是這樣做的—不過一旦開始專門處理這項任務，很多朋友可能會像我們一樣問自己“為什麼我們非要用PHP不可?”
命名約定的不一致性與特殊性
大家知不知道我們什麼時候需要用到下劃線符號?可以看到，base64_encode方法中用到了下劃線，但urlencode則沒有。此外，php_uname這一名稱中使用了下劃線，而phpversion則沒有。為什麼會這樣?有沒有人考慮過這個問題?大家有沒有編輯過API?
與此同時，strcmp函式是不能夠大寫的，但strcasecmp卻可以。另外，strpos不能大寫，stripos則可以。到底是其中的字母“i”決定了能否大寫，還是函式整體名稱決定的?誰能記得住這麼多亂七八糟的規則?當然，開發者們必須得記清楚。
災難般的排序
我們到底需要多少種排序函式?Java擁有一項基礎排序函式外加一個適用於所有物件的簡單介面。如果大家希望使用其它演算法、動手新增進去即可，而且大多數情況下標準函式已經完全夠用。而在PHP這邊，光是排序函式就能列出一條長長的清單：usort、sort、uksort以及array_sort等等(請注意，其中有一些還需要用到下劃線)。所以，請大家馬上把這些內容記到小本上，並祈禱自己在實際使用時不會搞混吧。
開源存在一定侷限性
PHP也許確實擁有開源的諸多優勢，但快取等卓越功能卻只存在於商用版本當中。當然，這就是現實社會，畢竟Zend需要藉此賺取利潤。再有，該公司還需要通過向特定使用者群體出售最佳版本的方式支援整個PHP專案。抱怨這一點就像抱怨地心引力帶來的不便一樣，正確但卻毫無意義—地球就在那裡，根本不鳥你喜不喜歡。請大家活得理性一些，別總幻想著人們都能活在烏托邦式的開源環境當中。
糟糕的名稱空間
大家有沒有建立自己函式的打算?如果有，請首先確定到底要使用PHP 5.3或者其後續版本，因為這裡正是命名空間出現的分界線。如果大家希望使用早期版本，則必須確保編碼內容與庫之間不存在衝突—畢竟在早期發展階段，PHP中的所有內容都具備全域性化屬性。如果大家決定使用PHP 5.3並接受名稱空間的加入，那麼請作好準備迎接“反斜槓”—一個醜陋的標點符號—的降臨。
糟糕的type安全
這個問題簡直可怕，首先舉個PHP程式設計師們喜聞樂見的例子：
(string)"false"
(int)0
請注意，這並不屬於那種某些PHP支持者所爭論的“函式副作用”的典型情況。畢竟t當中也包含著大量由於type轉換所引發的同類情況。事實上，這一行 想表達的是：左側為字串，右側為一個整數。只不過左側與右側內容完全相等。照這樣說來，如果讓PHP的設計者負責管理、世界上的每個人都能彼此和睦相處。
