在開發過程中,函式的返回值型別應該是確定不變的,但PHP是弱型別的語言,所以PHP是沒有此類語法驗證的,正因為如此,造成了很多坑坑。
比如下面的程式碼:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
<?php function getArticles(...){ $arrData = array(); if($exp1){ return $arrData; }else if($exp2){ return 1; }else{ return false; } } $arrData =getArticles(...); foreach($arrData as $record){ //do something. .... } ?> |
函式getArticles根據不同的條件返回不同型別的值,有bool、int、還有陣列,正常情況這類函式是希望返回陣列,然後拿陣列去做一些其他操作,可因為函式返回值型別不固定,呼叫時就很可能產生各種預想不到的坑,因此我就想,既然不能規範,那直接強制好了。
函式/方法返回值可以強制型別:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
int function a(){ ...... return 1; } bool function b(){ ...... return false; } array function c(){ ...... return array(); } object function d(){ ...... return new a(); } |
支援四種強制型別限制:int、array、bool、object,當返回值與函式宣告中的型別不匹配時,丟擲warning,本來想丟擲error,但是覺得太狠了,只能算是個異常,不能算錯誤,所以就用warning好了。
PHP本身是不支援 int function 這樣的語法的,所以要支援,就先要搞定語法解析器,關於語法解析器,可以移步這裡»>檢視詳情,這裡就不講了,
先修改語法掃描 Zend/zend_language_scanner.l檔案
增加如下程式碼:
1 2 3 4 5 6 7 8 9 10 11 12 |
<ST_IN_SCRIPTING>"int" { return T_FUNCTION_RETURN_INT; } <ST_IN_SCRIPTING>"bool" { return T_FUNCTION_RETURN_OBJECT; } <ST_IN_SCRIPTING>"object" { return T_FUNCTION_RETURN_OBJECT; } <ST_IN_SCRIPTING>"resource" { return T_FUNCTION_RETURN_RESOURCE; } |
意思很簡單,掃描器掃描到到關鍵字 int、bool、object、resource、array時返回相應的T_FUNCTION_* ,這是一個token,scanner根據不同的token做不同的處理,token要先在Zend/zend_language_parser.y檔案中定義
增加如下程式碼
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
.......... %token T_FUNCTION_RETURN_INT %token T_FUNCTION_RETURN_BOOL %token T_FUNCTION_RETURN_STRING %token T_FUNCTION_RETURN_OBJECT %token T_FUNCTION_RETURN_RESOURCE 1 然後增加token處理邏輯: 1 function: T_FUNCTION { $$.u.opline_num = CG(zend_lineno);$$.u.EA.var = 0; } | T_FUNCTION_RETURN_INT T_FUNCTION { $$.u.opline_num = CG(zend_lineno); $$.u.EA.var = IS_LONG; } | T_FUNCTION_RETURN_BOOL T_FUNCTION { $$.u.opline_num = CG(zend_lineno); $$.u.EA.var = IS_BOOL; } | T_FUNCTION_RETURN_STRING T_FUNCTION { $$.u.opline_num = CG(zend_lineno); $$.u.EA.var = IS_STRING; } | T_FUNCTION_RETURN_OBJECT T_FUNCTION { $$.u.opline_num = CG(zend_lineno); $$.u.EA.var = IS_OBJECT; } | T_FUNCTION_RETURN_RESOURCE T_FUNCTION { $$.u.opline_num = CG(zend_lineno); $$.u.EA.var = IS_RESOURCE; } | T_ARRAY T_FUNCTION { $$.u.opline_num = CG(zend_lineno); $$.u.EA.var = IS_ARRAY; } |
$$.u.EA.var 儲存的是 函式返回型別,最後要拿他來跟返回值型別做匹配,這樣語法直譯器就可以處理我們新的php語法了。這還不夠,還需要修改函式宣告定義的處理邏輯Zend/zend_compile.c ::zend_do_begin_function_declaration
1 2 3 4 5 6 7 8 9 10 11 12 13 |
...... zend_op_array op_array; char *name = function_name->u.constant.value.str.val; int name_len = function_name->u.constant.value.str.len; int function_type = function_token->u.EA.var; //儲存函式型別,在語法直譯器中增加的 int function_begin_line = function_token->u.opline_num; ...... op_array.function_name = name; op_array.fn_type = function_type; //將型別儲存到op_array中, op_array.return_reference = return_reference; op_array.fn_flags |= fn_flags; op_array.pass_rest_by_reference = 0; .......... |
PHP是先解析PHP語法生成相應的opcode,將需要的環境、引數資訊儲存到execute_data全域性變數中,最後在通過execute函式逐條執行opcode,所以要做處理就要把函式的型別儲存到opcode中:op_array.fn_type = function_type;
op_array是沒有fn_type的,要修改op_array的結構,增加zend_uint fn_type;
最後要修改opcode的毀掉函式,函式的返回 return 會生成token T_RETURN,T_RETURN會根據返回的型別呼叫不同的calback函式:
1 2 3 |
ZEND_RETURN_SPEC_CONST_HANDLER ZEND_RETURN_SPEC_TMP_HANDLER ZEND_RETURN_SPEC_VAR_HANDLER |
它有三個callback,如果返回值是一個 const型別的資料,則 ZEND_RETURN_SPEC_CONST_HANDLER
返回值是臨時資料,如 : return 1,則ZEND_RETURN_SPEC_TMP_HANDLER
返回值是一個變數,如 : return $a,則ZEND_RETURN_SPEC_VAR_HANDLER
所以要在這三個callback函式中增加處理邏輯:
在callback函式return之前增加如下程式碼
1 2 3 |
if((EG(active_op_array)->fn_type > 0) && Z_TYPE_P(retval_ptr) != EG(active_op_array)->fn_type){ php_error_docref0(NULL TSRMLS_DC,E_WARNING, "function name %s return a wrong type.", EG(active_op_array)->function_name ); } |
fn_type 去跟 返回值的型別作比較,如果沒有匹配到,就會丟擲這個warning。我已經打了補丁,目前只支援php5.3版本,有需要的可以拿去玩一玩。不清楚為什麼官方不支援此語法,我覺得還是挺有必要的。
下載補丁:php-syntax.patch
續:
後來有找鳥哥聊過,下面是他的回答:
“這個話題, 基本也是郵件組的月經貼了…. 1. 因為PHP是若型別, 很多型別可以互相轉換, 那麼到底要不要隱式轉換, 你的實現是不轉換, 這樣的侷限太大, 如果轉換又涉及到各種轉換規則. 2. 也不是不支援, 不過你的這個實現肯定是不夠的(各種自定類,和繼承類). 3. 以後如果要做jit, 可能會考慮支援.”
如此看來,這個問題官方也是比較糾結的,確實是我的思路是不強制轉換,只需要丟擲警告就行了,讓開發人員自己決定是否轉換,是不是更好?