요약: PHP 언어의 창시자인 Rasmus Lerdorf는 1968년에 태어나 올해 51세입니다. 그는 1995년에 Personal Home Page Tools라는 이름으로 PHP 1.0을 출시했습니다. 그의 영광은 야후의 검색 감소로 인해 어두워졌습니다.
1997년 이스라엘 프로그래머 Zeev Suraski와 Andi Gutmans는 Zend Company의 PHP 언어 개발에 합류하여 PHP 3, PHP 4, PHP 5를 출시했습니다. 참고로 PHP 6은 없고 현재는 PHP 7입니다. 1975년에 태어난 Zeev Suraski는 Zend에서 20년 동안 근무해 왔습니다. 어쩌면 언어, 건축, 도서관 업무에서 발전 방향을 찾을 수 없을지도 모르겠습니다.
며칠 전 Zeev Suraski가 Zend에서 사임을 발표했습니다. 업계는 상당히 놀랐습니다. PHP 7 최적화 개발자 Niao Ge는 이것이 오랫동안 계획된 일이라고 말했습니다. Zeev Suraski는 P++를 하고 싶었기 때문에 사임한 것으로 밝혀졌습니다. 그렇다면 P++란 무엇입니까? 그는 "P++ 아이디어: FAQ"를 통해 답변했고, 저자는 전문을 번역했습니다.
원본 번역:
이것은 Internals@에 있는 PHP 내부 개발자를 위한 메일링 리스트입니다. (internals@: PHP 내부 개발자 메일링 리스트. 여기에는 PHP의 개발 메커니즘이 포함됩니다. 내부 논의가 성숙해지면, 외부에 공개됩니다. 일반적으로 RFC 및 릴리스 공지에 제시된 아이디어에 대한 FAQ 설명으로, 후속 논의에서 반복적으로 제기된 많은 문제를 해결하려고 시도합니다.
참고: P++는 임시 코드 이름이며 향후 변경될 수 있습니다.
대체 무슨 일이 일어나고 있는 걸까요?
긴 이메일 내용을 몇 가지 요점으로 압축하려고 합니다.
1 PHP 세계에는 두 개의 큰 캠프가 있습니다. 첫 번째는 일반적으로 강력한 BC 편향(BC: Backward Compatibility, 하위 호환성이라고도 함, 이전 버전과 호환 가능, 즉 업그레이드된 소프트웨어는 이전 버전의 호환성을 고려해야 함)이 있는 PHP의 역동성을 좋아합니다. 예를 들어 Word of Office 2019는 기본적으로 .docx 파일 형식을 사용하지만 Office 2017/2013/2010 또는 심지어 2003의 .doc 형식도 열 수 있습니다. 상대적인 개념은 FC라고 하며, 이는 전방 호환(Forward Compatibility)이라고도 합니다. 즉, 업그레이드된 소프트웨어는 향후 호환성을 고려합니다. 이는 일반적으로 단순성에 특히 중점을 두고 향후에도 계속 적용될 소프트웨어의 특정 인터페이스 및 규칙입니다. 또 다른 선호는 그것을 줄이는 것입니다. 더 높은 수준과 더 복잡한 기능을 갖춘 더 엄격한 언어를 사용하는 것입니다.
2. 여기에는 '옳음'이나 '그름'이 없습니다. 두 장르 모두 유효하며 매우 헌신적인 추종자를 가지고 있습니다. 그러나 두 진영 모두에 맞는 언어를 만드는 것은 어려운 일이며, 이는 Internals@에 대한 지속적인 논쟁의 원천입니다.
3. 제안은 PHP와 함께 존재하지만 언어 뒤에 숨은 역사적 철학에 얽매이지 않는 새로운 PHP 방언(코드명 P++)을 만드는 것입니다. 즉, 이 새로운 방언은 본질적으로 더 제한적일 수 있으며, 이전 버전과의 호환성을 제거하고 "수하물"로 간주되는 요소(예: 짧은 태그)를 제거하고 더 복잡한 기능을 추가하는 데 더 대담할 수 있습니다. PHP 방언과 동일한 복잡성을 도입하지 않고 엄격한 유형의 언어에 매우 적합합니다.
4. 이것은 PHP 코드 브랜치가 아닙니다. 코드베이스는 동일하며 이를 작업하는 개발자도 동일합니다. 대부분의 코드는 동일합니다. 두 방언 사이의 특정 차이점만 다르게 구현됩니다. 이는 규모가 더 크다는 점만 제외하면 PHP 7에서 strict_types가 수행한 것과 다소 유사합니다.
정말 짧은 태그를 포기할 수 없는 사람들이 있다고 해서 우리가 이걸 할 건가요?
이것은 짧은 태그와 관련이 없습니다. "짧은 태그 RFC 사용 중단(RFC: Request for Comments, 언어 기능 추가, 표준화된 변경 관리 방법). 일반적으로 새로운 기능이 추가되면 RFC가 제출됩니다. 예를 들어, 변경 위원회 평가를 통과한 후 언어는 구현 소스 코드에 병합되어 새 버전에 통합됩니다."는 이 아이디어의 주요 동기가 아닙니다. 이 제안의 목표는 더욱 야심찬 것입니다. 이는 PHP에 대한 명확한 비전을 제공하고 두 진영이 원하는 것을 제공함으로써 마침내 두 진영 간의 긴장을 해결하기를 희망하는 것입니다.
PHP를 포크하는 이유는 무엇인가요?
이것은 분할이 아닙니다. 코드 베이스는 완전히 동일할 것이며 동일한 사람들에 의해 개발될 것입니다. 바이너리는 완전히 동일합니다. PHP를 설치하면 P++도 설치되며 그 반대의 경우도 마찬가지입니다. 동일한 바이너리가 PHP, P++ 또는 결합된 PHP/P++ 애플리케이션을 실행합니다.
파일이 어떻게 P++ 파일로 "표시"되는지는 확실하지 않지만 다음과 같이 파일 상단에 일종의 특수 태그일 수 있습니다.
<?p++?> <?php 'Hello, world!'; ?>
또한 전체 네임스페이스를 표시하는 방법을 찾을 수도 있습니다. P++ 로 지정되므로 프레임워크는 각 개별 파일을 명시적으로 P++로 표시할 필요가 없습니다.
이는 개발 작업량이 두 배로 늘어난 반면 Internals@의 기여자는 이미 적다는 것을 의미합니다. 우리는 그것을 어떻게 처리합니까?
다행히 그런 뜻은 아닙니다(작업량 두 배). 대부분의 코드는 소스 코드와 런타임 모두 PHP 모드와 P++ 모드 간에 공유됩니다.
실행 중인 파일이 PHP 파일이든 P++ 파일이든 데이터 구조, 주요 하위 시스템, 확장, 웹 서버 인터페이스, OPcache 및 기타 모든 코드는 정확히 동일한 코드입니다. 유일한 추가 개발 오버헤드는 PHP와 P++의 차이점입니다.
실제로 이는 특정 코드 조각의 두 가지 버전을 유지해야 함을 의미하며 P++는 PHP에 비해 추가 검사가 있을 수 있으므로 여기저기에 if() 문이 있어야 합니다. 그러나 더 엄격한 PHP 버전으로 전환하려면 이러한 요소를 도입해야 합니다. 더욱이 엄격한 진영에 있는 사람들조차도 마이그레이션 경로를 제공하지 않고 미래의 엄격한 버전으로 이동하는 것을 권장하지 않습니다. 실제로 이 접근 방식에 수반되는 노력은 거의 모든 접근 방식과 유사합니다.
더 엄격한 PHP 8/9로 전환하면 영구적으로 유지 관리되는 PHP 7.4 장기 유지 관리 릴리스를 개발하는 것이 어떨까요?
이 방법에는 문제가 많습니다. 기능이나 성능 업데이트 없이 엄청난 동적 선호도를 유지한다는 사실을 무시하더라도 개발 노력 관점에서 볼 때 비실용적입니다. 이는 실제로 사실상 포크를 의미하는 이 제안과는 다릅니다.
PHP와 P++ 중 하나를 선택해야 하나요?
예, 아니오. 위에서 언급했듯이, 하나를 설치하면 다른 하나도 갖게 되며, 애플리케이션에 관한 한 두 방언을 하나의 서버에서 실행할 수 있습니다. 그러나 실제로는 엄격한 유형의 경우와 마찬가지로 프로젝트와 개인이 둘 중 하나를 선택하고 표준화하는 경우가 많습니다.
동일한 애플리케이션에서 PHP와 P++를 혼합할 수 있나요?
그렇습니다. 정확한 메커니즘을 결정해야 하지만 코드가 PHP인지 P++인지에 대한 지정은 요청 수준이 아닌 파일 수준에서 이루어집니다. 단일 실행(요청)으로 두 방언 모두에서 다양한 파일을 로드할 수 있습니다. PHP 파일의 코드는 PHP 의미 체계로 작동하고, P++ 파일의 코드는 P++ 의미 체계로 작동합니다. 이는 strict_types와도 유사합니다.
처음에는 어색하게 들릴 수도 있지만 매우 실용적인 사용 사례가 있을 수 있습니다. 예를 들어, PHP 애플리케이션은 P++ 전용 프레임워크를 사용하고 그 반대의 경우도 마찬가지입니다. C와 C++에 익숙한 사람들에게는 이는 다소 유사합니다.
이것은 PHP가 더 이상 발전하지 않는다는 뜻인가요? 모든 새로운 기능이 P++에 제공되나요?
아니요, 단지 다르게 발전할 것이라는 뜻일 뿐입니다. 엄격함과 유형 관련 기능은 P++에서만 사용할 수 있으며 P++ 파일에서만 사용할 수 있습니다. 이전 버전과의 호환성 편향은 PHP에 그대로 남아 있습니다(이는 이전 버전과의 호환성이 절대 깨지지 않는다는 의미는 아니며, 각 경우에 대해 좋은 ROI 사례가 있어야 함을 의미합니다).
그러나 엔진 성능 향상(예: JIT), 확장 개발 또는 새로운 비동기 관련 기능 등 이와 관련되지 않은 기능은 PHP와 P++ 모두에서 사용할 수 있습니다.
이 방법의 장점은 무엇인가요?
이 방법에는 많은 이점이 있습니다. 첫째, 내부@ 양쪽 진영에 모두 좋은 솔루션을 제공합니다. PHP의 동적 특성을 선호하는 사람들은 이를 유지할 수 있으며, 보다 엄격한 유형의 언어를 선호하는 사람들은 PHP 제한 없이 얻을 수도 있습니다. 대안은 한 진영의 승리가 다른 진영의 패배이고 그 반대의 경우도 마찬가지인 제로섬 게임입니다.
최소한의 노력으로 전체 청중을 지원할 수 있는 좋은 기술 솔루션을 설계하는 것 외에도 최근 몇 년 동안 내부 @에 대한 주요 논쟁의 원인이 될 것입니다.
마지막으로, 이 문서의 독자 대부분은 기술적인 사람들일 가능성이 높지만, P++ 출시는 과거에 관계없이 새로운 출발점에서 다시 시작되며 엄청난 포지셔닝 및 브랜딩 이점을 가져올 수 있다는 점에 유의해야 합니다. PHP를 사용하지 않는 기업, 개발 관리자, 개인 개발자는 PHP 8.0이나 PHP 9.0의 도입보다 P++의 도입에 더 주목하게 될 것입니다.
사용자 기반을 분할할 위험은 없나요?
어떤 면에서는 그렇습니다. 그러나 이것은 아이디어의 결함이 아니라 이미 존재하는 현실의 표현입니다.
위에서 언급했듯이 PHP의 동적 특성을 좋아하고 PHP를 점점 더 유형 지향적으로 만드는 것을 경계하는 사람들이 많이 있습니다.
한편, PHP를 보고 스스로 생각하는 또 다른 그룹이 있습니다. "왜 이렇게 느려져서 이 역동적인 넌센스를 포기하게 되는 걸까?"
여기에는 옳고 그름이 없습니다. 두 가지 견해가 모두 유효합니다. 이러한 두 가지 상충되는 관점을 연결하기 위한 가능한 솔루션을 살펴보면 사용할 수 있는 방법이 많지 않습니다.
1. 동적 PHP를 고수하세요. 이것은 더 엄격한 언어를 옹호하는 사람들에게는 받아들여지지 않을 것입니다.
2. 엄격한 PHP를 지향하여 개발하세요. 동적 언어 지지자들은 이를 받아들이지 않을 것입니다.
3. 코드 베이스를 포크합니다. 어떻게 진행되든 참여자 모두에게 순손실 옵션이 됩니다. 이렇게 하면 기술적인 이점이 없으며, 원하더라도(원하지 않음) 이를 수행할 수 있는 기여자가 충분하지 않습니다.
4. 두 청중의 요구를 모두 충족할 수 있는 창의적인 솔루션을 생각해 보세요. 이것이 바로 이 제안이 시도하는 것입니다. 이는 프로젝트 자체를 통일된 상태로 유지하면서 두 방언 간의 영구적인 상호 운용성을 보장합니다. 어느 정도 단편화되더라도 모든 사람의 주요 요구 사항을 충족할 수 있는 최소한의 수준입니다.
이것이 니키타 (버전에 기능 추가를 제안한 내부 연사 @. 그런데 미국 TV 시리즈 "니키타"는 볼만한 가치가 있습니다.) 버전의 아이디어와 어떻게 다른가요?
이 두 아이디어에는 많은 유사점이 있지만 상당한 차이점도 있습니다. 이는 버전 방법론에 대한 제한된 이해를 기반으로 한 것이므로 부분이 부족하거나 부정확하거나 정확하지 않을 수 있습니다.
1. 이 제안에는 현재의 동적 유형 PHP를 장기적으로 완벽하게 지원되는 동등한 피어 방언으로 유지하려는 명확한 목표가 있습니다. 릴리스 접근 방식은 현재 동작을 "레거시"로 처리합니다. 이는 권장되지 않는(사용되는) 다음 어느 시점에서는 더 이상 사용되지 않고 제거될 수 있음을 의미합니다.
2. 출시 전략이 전혀 다릅니다. P++ 제안은 먼저 엄격한 연산, 유형 변환 논리 변경, 배열 인덱스 처리, 변수 선언 요구 등과 같은 호환성을 깨는 요소에 초점을 맞추고 이를 P++ 창간호에 제공하는 것을 목표로 합니다. 이것의 목적은 더 많은 호환성 변경이 도입될 때 1~2년 안에 대대적인 재작성을 해야 할 수도 있다는 사실을 알지 못한 채 새로운 프로젝트/프레임워크를 새로 시작할 수 있도록 하는 것입니다. 버전 관리 제안에는 그러한 목표가 없는 것 같지만 대신 PHP에서 요소를 점진적으로 추가/변경하는 것을 목표로 합니다.
3. 롤아웃 접근 방식과 관련하여 버전 관리 접근 방식은 두 가지 방언만 허용하는 것이 아니라 여러 방언을 허용합니다. PHP2020 방언뿐만 아니라 PHP2022 방언과 PHP2027 방언도 있을 수 있습니다. 이를 모두 유지하면 실제로 유지 관리가 더 복잡해질 수 있습니다.
4. 또한 이 제안에서는 PHP와 P++에 대한 다양한 하위 호환성 중단 전략(보수적 vs. 공격적)을 언급하지만 버전 관리 체계에서는 해당 주제를 전혀 다루지 않을 수 있습니다.
5. 버전 제안은 포지셔닝/마케팅 측면에서 이 제안과 정확히 동일하지 않습니다.
이 두 가지 아이디어가 반드시 상호 배타적인 것은 아니라는 점에 유의하는 것이 중요합니다. 우리는 P++를 도입하고 버전을 사용하여 이를 개선할 수 있습니다. 특히 모든 중요한 변경 사항을 P++의 첫 번째 호에 적용하기 어려운 경우에는 더욱 그렇습니다.
어떤 과제가 있나요?
첫 번째 P++ 애플리케이션을 실행하기 전에는 어려움이 많았습니다.
1. 지원이 필요합니다. 이는 양 진영의 사람들이 PHP를 완전히 동적으로 만들거나 완전히 형식화하려는 꿈을 포기하고 자신과 다르게 생각하는 사람들을 무시해야 함을 의미합니다. 이는 매우 중요한 도전인 것 같습니다.
2 성공하려면 P++의 첫 번째 버전은 PHP의 호환성을 깨는 변경 사항을 모두 또는 적어도 대부분 처리해야 합니다. 미래 코드. 일부에서는 개발자의 제한된 역량으로 인해 너무 낙관적이어서 한 권에 출시하지 못할 수도 있다는 우려를 표명했습니다. 목록의 내용에 대해 더 잘 알게 되면 이를 평가해야 합니다. 이는 첫 번째 호에서 P++에 대해 가질 수 있는 모든 아이디어를 구현해야 한다는 의미는 아니며, 많은 최종 사용자 코드 재작성을 유발하는 요소의 우선순위를 지정하고 첫 번째 호에서 이를 처리하기 전에 이를 시도해야 한다는 의미입니다. .
3. 물론 가장 어려운 일은 이 새로운 방언에 대한 합리적인 이름을 찾는 것입니다.
관련 추천:
4. 5.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
