PHP 7과 연관된 RFC 이야기
며칠 전에 PHP 7 alpha 첫 버전이 나왔다. 나는 호기심에 PHP의 feature들이 어떤 과정으로 결정되었는지 살짝만 찾아보았는데, PHP 7에 추가하자고 제안된 기능들을 몇가지 살펴보고, PHP의 의사결정 방식을 좀 알아보고자 한다.
1. PHP 4식의 생성자 제거
통과되었다.
사실 PHP를 Modern하게 쓰는 사람 중에 이 방식을 아직도 쓰는 사람은 없었을거라고 생각한다. 사라져도 아무 상관 없을거라고 생각한다.
2. Spaceship operater
통과되었다.
이것이 뭔지 잘 모르는 분들을 위해 간단히 설명드리자면 strcmp의 연산자 버전이라고 설명드리면 될 것 같다. 다만 보다 더 많은 변수형을 처리할 수 있다.
이것은 정렬시에 key 함수를 만들때 편리한 연산자이다. 까놓고 말하자면 usort 함수를 위해 만들어졌다고 해도 과언이 아닐 것이다.
하지만 문서 스팩 어디를 보아도 PHP의 내재적인 변수형 캐스팅(타입 저글링이라고 한다)에 대해 말하고 있지 않다. 즉, 우리는 "1ee" <=> 1 의 결과로 true가 나오는 상황을 보게 될지도 모른다.
3. json 구현을 jsond로 변경
통과되었다.
사용자단에서는 아무것도 변하지 않을 것 같다. 그래서 그런지 PHP: a fractal of bad design에서 지적된 json_decode에 잘못된 json 문자열이 들어가면 null이 나오는데 원래 json 자체가 null이었는지 확인하려면 json_last_error를 매번 호출해봐야만 하는 이상함도 고스란히 따라올 것 같다.
4. Return type 정의법과 Scalar type hint
통과되었다.
사실 이것이 통과되면 가장 득을 보는 것은 정적 분석기일것이라고 생각한다. PHPStorm등의 편의성이 비약적으로 상승할 것이라고 생각한다.
하지만 strict하게 제한하지 않으면 사용하는 의미가 떨어지고, 제한하면 난장판이 될 가능성이 농후하다. 해당 제안에도 적혀있지만 PHP는 변수형을 자기 맘대로 casting해버리는 경향이 있어서 int형이 올지 float형이 올지 예상할 수 없다던가 하는 문제들이 기다리고 있다.
그리고 PHP는 변수형이 날뛰는 언어이다보니 이것이 개발에 독이 될지도 모른다는 느낌도 없지 않다.
나는 그것보다, PHP의 수천개의 내장 함수들도 strict모드를 지원할지가 더 궁금하다. 가령 PORT 넘버를 string으로 넘기면 안된다던가 하는 제약을 할 것인가 하는 부분이다. 그렇게 하지 않으면 사용자가 실수한 것은 찾을 수 있겠지만 내장 함수를 잘못 쓴 것은 영영 찾을 수 없을 것이다.
5. 파라메터 생략하기
거절당했다
간단히 말하자면 default라는 키워드 같은것을 둬서, 함수를 실행할때 특정 인자를 생략하는 기능이다.
Python에서는 직접 파라메터명을 콕 찝어서 인자를 넣을 수도 있다. 하지만 PHP는 이미 named parameter를 추가하고 싶지 않다고 밝힌 바 있다. 불쌍한 PHP 개발자들은 default값을 모르면 소스를 까봐야하는 처지가 되었다.
6. in 연산자
거절당했다
간단히 말하자면 문자열, 배열등의 자료형에서 특정 내용이 있는지 검색하기 쉽게 하는 연산자다. 하지만 거절당했다. 그냥 in_array나 strpos 같은 것을 사용하길 바라는 것 같다.
7. 내장 클래스의 생성자 동작
통과되었다
내장 클래스, 이를테면 PDO 같은것에 factory method를 넣자는 이야기다. 이것이 되면 new 연산자를 안써도 되고, try - catch로 묶지 않아도 예외처리를 할 수 있다. 대신 ::create라는 static method를 써야하겠지만.
8. E_STRICT의 제거
통과되었다
E_STRICT에 해당하는 에러는 많지 않았는데, 이것을 그냥 다른 에러에 분배해주고 없애자는 이야기다. 사실 4번에 의해 이미 strict_type이란것이 생겨버렸기 때문에 차후를 생각해서라도 없애는것이 맞지 않나 싶다.
9. 강력한 함수 인자 갯수 검사
취소되었다
PHP로 여러개의 인자를 던져주는 함수를 만드려면 더러운 마법을 많이 써야하는데, 그 경우에 인자 갯수 검사 같은것을 말하는 것이다. RFC를 직접 보면 알 수 있지만 꽤나 복잡하다.
10. 익명 클래스
통과되었다
이름을 정하지 않은 class를 만들어서 사용할 수 있다. PHP의 패러다임을 바꿔버릴 수도 있다고 생각하지만 아직 PHP의 namespace가 변수는 불러다 쓸 수 없는 관계로 모르겠다. 일단 매우 환영할만한 일이라고 생각한다.
다만, 소스의 복잡도는 옛날보다 더 오를테니 깊이 들어갈수록 개발자의 머리가 아프긴 할 것 같다.
보면 알겠지만 나는 이 사람들의 의사결정 방식을 이해할 수 없다. 뭔가 좀 더 논쟁이 있을법한 부분들이 문서에 남아있지 않아서 왜 저런 결정이 나왔는지 알 수가 없다. 가령 in 연산자는 구현되면 매우 편리할것이 자명한데 반대한 사람이 과반을 넘는다. 하지만 왜 그렇게 되었는지는 단 한마디도 언급이 없다. 이 사람들은 무엇이 하고 싶은걸까?
아직도 PHP: a fractal of bad design에서 지적된 문제들이 상당량 방치되고 있다. 가령 T_PAAMAYIM_NEKUDOTAYIM 에러 같은 것들 말이다. (PAAMAYIM NEKUDOTAYIM이란 히브리어로 ‘double colon’이란 뜻이다. 세상에! )
언어의 버전은 이미 올라가기로 확정되었고, 상당량의 feature는 freeze된 상태다. 하지만 아직 PHP의 갈 길은 멀어보인다.
