PHP에서 제네릭을 사용할 수 없는 이유를 분석해 보겠습니다.-PHP 튜토리얼-php.cn

PHP에서 제네릭을 사용할 수 없는 이유를 분석해 보겠습니다.

WBOY

풀어 주다： 2023-04-10 22:38:01

앞으로

5586명이 탐색했습니다.

이 기사에서는 PHP에 대한 관련 지식을 제공합니다. 주로 PHP에서 제네릭을 사용할 수 없는 이유를 소개합니다. 다음으로 제네릭이 아직 지원되지 않는 이유를 이해하기 위해 제네릭과 PHP의 상황을 살펴보겠습니다. 이것은 모두에게 도움이 됩니다.

PHP에서 제네릭을 사용할 수 없는 이유를 분석해 보겠습니다.

PHP에서 제네릭을 사용할 수 없는 이유

제네릭과 PHP 뒤에 무슨 일이 일어나고 있는지 자세히 알아 보겠습니다. 제네릭이 아직 PHP에서 일급 시민으로 지원되지 않는 이유를 이해하는 것은 매우 흥미롭고 중요합니다.

PHP에서 제네릭을 사용할 수 없는 이유를 분석해 보겠습니다.

보죠.

PHP에는 제네릭이 없습니다. 이것이 작년 니키타의 결론입니다. 이것은 단순히 실현 가능하지 않습니다.

니키타가 이렇게 말한 이유를 이해하려면 제네릭이 어떻게 구현되는지 살펴봐야 합니다. 일반적으로 세 가지 가능한 접근 방식이 있습니다. 제네릭을 지원하는 프로그래밍 언어는 대부분 이 세 가지 접근 방식 중 하나를 사용합니다.

첫 번째는 단일형 제네릭이라고 합니다. 이 시리즈의 첫 번째 기사로 돌아가서 이 컬렉션 예제를 보여드리겠습니다.

class StringCollection extends Collection
{
    public function offsetGet(mixed $key): string 
    { /* … */ }
}
class UserCollection extends Collection
{
    public function offsetGet(mixed $key): User 
    { /* … */ }
}

로그인 후 복사

필요한 각 컬렉션 유형에 대해 컬렉션 클래스 구현을 수동으로 생성할 수 있다고 설명했습니다. 작업량이 엄청나고 코드도 많지만 작동할 것입니다.

단형 제네릭은 정확히 이 작업을 수행하지만 뒤에서는 자동으로 수행합니다. 런타임 시 PHP는 일반 Collection 클래스에 대해 알지 못하지만 두 개 이상의 특정 구현에 대해서는 알지 못합니다.

$users = new Collection<User>();
// Collection_User
$slugs = new Collection<string>();
// Collection_string

로그인 후 복사

단형 제네릭은 완벽하게 유효한 접근 방식입니다. 예를 들어 Rust는 이를 사용합니다. 이것의 한 가지 장점은 런타임에 더 이상 일반 유형 검사가 없기 때문에 일련의 성능 개선이 있다는 것입니다. 따라서 이러한 검사는 코드를 실행하기 전에 분리됩니다.

그러나 이는 즉시 PHP의 단일형 제네릭 문제로 이어집니다. PHP에는 Rust처럼 일반 클래스를 여러 구체적인 구현으로 분리하는 명시적인 컴파일 단계가 없습니다. 결론은 다음과 같습니다. 단일형 제네릭은 동일한 클래스의 여러 복사본을 만들기 때문에 꽤 많은 메모리가 필요합니다. 약간의 차이점이 있습니다. 이는 컴파일된 Rust 바이너리에는 큰 문제가 아닐 수 있지만 중앙 지점(서버)에서 실행되는 PHP 코드에는 잠재적으로 초당 수백 또는 수천 개의 요청을 처리하는 데 심각한 문제가 됩니다.

다음 옵션은 제네릭을 구체화하는 것입니다. 이는 일반 클래스가 그대로 유지되고 유형 정보가 런타임에 동적으로 평가되는 구현입니다. C#과 Kotlin은 PHP가 런타임에 모든 유형 검사를 수행하므로 PHP의 현재 유형 시스템에 가장 가까운 제네릭을 구현합니다. 여기서 문제는 구체화된 제네릭이 작동하도록 하기 위해 많은 핵심 코드 리팩토링이 필요하다는 것입니다. 그리고 런타임에 유형 검사를 점점 더 많이 수행함에 따라 일부 성능 오버헤드가 증가할 것이라고 상상할 수 있습니다.

이것은 마지막 옵션으로 이동합니다. 런타임 시 제네릭을 완전히 무시합니다. 예를 들어 컬렉션 클래스의 일반 구현은 어쨌든 모든 유형의 입력을 처리할 수 있습니다.

따라서 런타임 시 모든 일반 유형 검사를 무시하면 아무런 문제가 없습니다.

그렇게 빠르지는 않습니다. 런타임 시 일반 유형을 무시하면(유형 삭제라고 하며 Java와 Python에서는 이를 수행함) PHP에 몇 가지 문제가 발생했습니다.

예: PHP는 유효성 검사를 위해 유형을 사용할 뿐만 아니라 유형 정보를 사용하여 값을 한 유형에서 다른 유형으로 동적으로 변환합니다. 이것이 이 시리즈의 첫 번째 기사에서 언급한 유형 저글링입니다.

function add(int $a, int $b): int 
{
    return $a + $b;
}
add(&#39;1&#39;, &#39;2&#39;) // 3;

로그인 후 복사

If PHP 이 "문자열" 컬렉션의 일반 유형을 무시하고 실수로 여기에 정수를 추가하면 일반 유형이 제거되면 경고가 표시되지 않습니다.

$slugs = new Collection<string>();
$slugs[] = 1; // 1 不会被转换为 &#39;1&#39;

로그인 후 복사

유형 삭제 두 번째이자 더 중요한 문제 - 아마도 여러분은 지금 쯤 화면에 소리 지르면 장르가 사라지는 것입니까? 런타임 시 제네릭 유형이 제거되면 왜 추가합니까?

정적 분석기로 코드를 실행하기 전에 모든 유형 정의를 확인하기 때문에 이는 Java 및 Pyton에서 의미가 있습니다. 예를 들어 Java는 코드를 컴파일할 때 내장된 정적 분석기를 실행합니다. PHP에서는 전혀 수행하지 않는 작업입니다. 컴파일 단계도 없고 내장된 정적 유형 검사기도 없습니다.

반면에… 이전 기사에서 논의한 유형 검사의 모든 장점은 PHP에 내장된 런타임 유형 검사기에서 나오는 것이 아닙니다. PHP의 유형 검사기가 문제가 있다고 알려줄 때 우리는 이미 코드를 실행하고 있습니다. 유형 오류는 본질적으로 프로그램을 중단시킵니다.

대신, 유형 검사의 부가 가치 대부분은 코드를 실행할 필요가 없는 정적 분석기에서 나옵니다. 프로그래머가 충분한 유형 정보를 제공하는 한 런타임 유형 오류가 발생하지 않도록 할 가능성이 높습니다. 이는 코드에 오류가 없다는 의미는 아니지만 완전히 정적으로 검사되고 런타임 시 어떤 유형의 오류도 생성하지 않는 PHP 코드를 작성하는 것이 가능합니다. 결론: 코드를 작성하는 동안 모든 정적 통찰력을 얻습니다. 이는 런타임 유형 확인에 관계없이 모든 유형 시스템에서 가장 중요한 부분입니다.

그럼 런타임 유형 검사가 정말 필요한가요? 이것이 현재 PHP에 제네릭을 추가할 수 없는 주된 이유이기 때문입니다. 런타임에 제네릭 유형을 검증하는 것은 PHP에 비해 너무 복잡하거나 리소스 집약적입니다.