>  기사  >  백엔드 개발  >  PHP7의 새로운 기능 중 추상 구문 트리(AST)에 대한 일부 소개

PHP7의 새로운 기능 중 추상 구문 트리(AST)에 대한 일부 소개

不言
不言원래의
2018-07-21 12:59:122192검색

이 기사에서는 PHP7의 새로운 기능인 추상 구문 트리(AST)에 대해 소개합니다. 내용이 매우 좋습니다. 도움이 필요한 모든 사람에게 도움이 되기를 바랍니다.

이 글에서는 PHP7의 새로운 기능인 AST(Abstract Syntax Tree)로 인한 변화를 분석합니다. 참조를 위해 모든 사람과 공유하세요. 세부 사항은 다음과 같습니다:

여기에 있는 대부분의 콘텐츠는 AST의 RFC 문서인 https://wiki.php.net/rfc/abstractsyntaxtree를 참조합니다. 이해를 돕기 위해 원본 문서에서 다음과 같은 내용을 발췌하여 소개합니다.

이 기사에서는 추상 구문 트리가 무엇인지 설명하지 않습니다. 이 기사에서는 AST가 PHP에 가져오는 몇 가지 변경 사항만 설명합니다.

새로운 실행 프로세스

PHP7 커널의 중요한 변화는 AST의 추가입니다. PHP5에서 PHP 스크립트에서 opcode까지의 실행 프로세스는 다음과 같습니다.

  1. Lexing: 어휘 스캐닝 분석, 소스 파일을 토큰 스트림으로 변환

    # 🎜🎜#
  2. 파싱: 구문 분석, 연산 배열이 이 단계에서 생성됩니다.

PHP7은 더 이상 구문 분석 단계에서 연산 배열을 직접 생성하지 않지만 AST를 먼저 생성하므로 프로세스에 한 단계가 더 있습니다:

#🎜 🎜## 🎜🎜#

Lexing: 어휘 스캐닝 분석, 소스 파일을 토큰 스트림으로 변환
  1. Parsing: 구문 분석, 토큰에서 추상 구문 트리 생성 스트림;
  2. Compilation: 추상 구문 트리에서 연산 배열을 생성합니다.
  3. 실행 시간 및 메모리 소모
위 단계에서 이전 과정보다 한 단계 더 진행되었으므로 상식을 따르세요. 이는 프로그램의 실행 시간과 메모리 사용량을 증가시킬 것이라고 말했습니다. 하지만 실제로는 메모리 사용량이 늘어난 것은 사실이지만 실행 시간은 줄어들었습니다.

소형(코드 약 100줄), 중형(약 700줄), 대형(약 2800줄)의 세 가지 스크립트를 테스트하여 얻은 결과는 다음과 같습니다. 테스트 스크립트: https://gist .github.com/nikic/289b0c7538b46c2220bc.

각 파일을 100번 컴파일하는 실행 시간(기사의 테스트 결과는 PHP7이 여전히 PHP-NG로 불렸던 14년 전이라는 점에 유의하세요): # 🎜🎜 #

php-ng# ㅋㅋㅋ 🎜# - 12.5% ​​MEDIUM1.492s1.268s-1 7.7% 에디토리얼 #🎜 🎜# 단일 편집의 메모리 최고치: # 🎜 🎜#378kB414kB+9.5%MEDIUM

php-ast
php-ng php-ast diff
SMALL#🎜🎜 #
# 🎜🎜 # 507 kB 4kB#🎜🎜 #

1857kB

+71.3%단일 테스트 결과 컴파일이 실제 사용을 나타내지 않을 수 있습니다. 이 경우 다음은 PhpParser를 사용한 전체 프로젝트 테스트의 결과입니다: 🎜🎜#TIMEMEMORY2360kB

php-ast diff
25.5ms 22.8ms -11.8% #🎜 🎜#
# 🎜🎜 #2482kB +5.1% #🎜 🎜##🎜 🎜#

테스트 결과, AST를 사용한 후 프로그램의 전체 실행 시간이 약 10%~15% 향상되었지만 메모리 소비도 증가하는 것으로 나타났습니다. 대용량 파일을 한 번 컴파일할 때 그 증가는 명백하지만 그렇습니다. 전체 프로젝트 실행 과정에서 증가하지 않습니다. 심각한 문제는 아닙니다.

또한 위의 결과는 모두 Opcache를 사용하지 않은 결과이므로 프로덕션 환경에서 Opcache를 켜면 메모리 소비 증가는 큰 문제가 되지 않습니다.

의미적 변경

단순한 시간 최적화라면 AST를 사용할 이유가 충분하지 않은 것 같습니다. 실제로 AST 구현은 시간 최적화 고려사항이 아니라 구문 문제를 해결하기 위한 것입니다. 의미론의 몇 가지 변화를 살펴보겠습니다.

yield에는 대괄호가 필요하지 않습니다.

PHP5 구현에서 yield에서는 <code>yield 선언의 양쪽에 대괄호를 사용해야 합니다: yield,你必须在 yield 申明两边使用括号:

<?php
$result = yield fn(); // 不合法的
$result = (yield fn()); // 合法的

这种行为仅仅是因为 PHP5 的实现方式的限制,在 PHP7 中,括号不再是必须的了。所以下面这些写法也都是合法的:

<?php
$result = yield;
$result = yield $v;
$result = yield $k => $v;

当然了,还得遵循 yield 的应用场景才行。

括号不影响行为

在 PHP5 中,($foo)['bar'] = 'baz'$foo['bar'] = 'baz' 两个语句的含义不一样。事实上前一种写法是不合法的,你会得到下面这样的错误:

<?php
($foo)[&#39;bar&#39;] = &#39;baz&#39;;
# PHP Parse error: Syntax error, unexpected &#39;[&#39; on line 1

但是在 PHP7 中,两种写法表示同样的意思。

同样,如果函数的参数被括号包裹,类型检查存在问题,在 PHP7 中这个问题也得到了解决:

<?php
function func() {
 return [];
}
function byRef(array &$a) {
}
byRef((func()));

以上代码在 PHP5 中不会告警,除非使用 byRef(func()) 的方式调用,但是在 PHP7 中,不管 func() 两边有没有括号都会产生以下错误:

PHP Strict standards:  Only variables should be passed by reference ...

list() 的变化

list 关键字的行为改变了很多。list 给变量赋值的顺序(等号左右同时的顺序)以前是从右至左,现在是从左到右:

<?php
list($array[], $array[], $array[]) = [1, 2, 3];
var_dump($array);
// PHP5: $array = [3, 2, 1]
// PHP7: $array = [1, 2, 3]
# 注意这里的左右的顺序指的是等号左右同时的顺序,
# list($a, $b) = [1, 2] 这种使用中 $a == 1, $b == 2 是没有疑问的。

产生上面变化的原因正是因为在 PHP5 的赋值过程中,3 会最先被填入数组,1 最后,但是现在顺序改变了。

同样的变化还有:

<?php
$a = [1, 2];
list($a, $b) = $a;
// PHP5: $a = 1, $b = 2
// PHP7: $a = 1, $b = null + "Undefined index 1"

这是因为在以前的赋值过程中 $b 先得到 2,然后 $a 的值才变成 1,但是现在 $a 先变成了 1,不再是数组,所以 $b 就成了 null。

list 现在只会访问每个偏移量一次:

<?php
list(list($a, $b)) = $array;
// PHP5:
$b = $array[0][1];
$a = $array[0][0];
// PHP7:
// 会产生一个中间变量,得到 $array[0] 的值
$_tmp = $array[0];
$a = $_tmp[0];
$b = $_tmp[1];

空的 list 成员现在是全部禁止的,以前只是在某些情况下:

<?php
list() = $a;   // 不合法
list($b, list()) = $a; // 不合法
foreach ($a as list()) // 不合法 (PHP5 中也不合法)

引用赋值的顺序

引用赋值的顺序在 PHP5 中是从右到左的,现在时从左到右:

<?php
$obj = new stdClass;
$obj->a = &$obj->b;
$obj->b = 1;
var_dump($obj);
// PHP5:
object(stdClass)#1 (2) {
 ["b"] => &int(1)
 ["a"] => &int(1)
}
// PHP7:
object(stdClass)#1 (2) {
 ["a"] => &int(1)
 ["b"] => &int(1)
}

__clone 方法可以直接调用

现在可以直接使用 $obj->__clone() 的写法去调用 __clone 方法。__clonerrreee

이 동작은 PHP5에서 대괄호 구현의 제한 때문입니다. 더 이상 필수가 아닙니다. 따라서 다음 작성 방법도 적법합니다.

rrreee

물론 yield의 적용 시나리오를 따라야 합니다.

괄호는 동작에 영향을 주지 않습니다

PHP5에서는 ($foo)['bar'] = 'baz'$foo ['bar'] = 'baz' 두 문은 서로 다른 의미를 갖습니다. 사실, 이전 작성 방법은 불법이며 다음과 같은 오류가 발생합니다:

rrreee

그러나 PHP7에서는 두 가지 작성 방법이 동일한 의미를 갖습니다. 마찬가지로 함수의 매개변수가 괄호 안에 있으면 유형 검사에 문제가 있습니다. 이 문제는 PHP7에서도 해결되었습니다. rrreee# 🎜🎜#PHP 엄격한 표준: 변수만 참조로 전달되어야 합니다... changes in list() list 동작 키워드가 많이 바뀌었어요. 목록이 변수에 값을 할당하는 순서(동시에 등호 주위의 순서)는 오른쪽에서 왼쪽이었지만 이제는 왼쪽에서 오른쪽입니다: rrreeeThe 위의 변경 이유는 정확히 PHP5의 할당 프로세스 때문입니다. 배열에 3이 먼저 채워지고 1이 마지막에 채워지지만 이제 순서가 변경되었습니다. 동일한 변경 사항은 다음과 같습니다. 이전 할당 과정에서 $b가 먼저 2를 얻은 후 $a의 값이 1이 되었지만 지금은 $ a 첫 번째는 1이 되고 더 이상 배열이 아니므로 $b는 null이 됩니다. list는 이제 각 오프셋에 한 번만 액세스합니다. rrreee 이전에는 특정 상황에서만 빈 목록 구성원이 모두 금지되었습니다. #🎜🎜 #rrreeerrreee이제 $obj->__clone()의 쓰기 메서드를 직접 사용하여 __clone 메서드를 호출할 수 있습니다. __clone은 이전에 직접 호출이 금지된 유일한 매직 메서드입니다. 이전에는 다음과 같은 오류가 발생했습니다. 새 구현에서는 이전 문법 표현의 의미가 현재와 다소 다릅니다. 자세한 내용은 아래 표를 참조하세요. #🎜 🎜#PHP7
위 코드 byRef(func())를 사용하여 호출하지 않는 한 PHP5에서는 경보가 발생하지 않지만 PHP7에서는 func()의 양쪽에 괄호가 있는지 여부에 관계없이 다음 오류가 발생합니다. code>:
rrreee
The 참조 할당 순서 참조 할당 순서는 PHP5에서 오른쪽에서 왼쪽으로, 현재 시제는 왼쪽에서 오른쪽으로: __clone 메서드를 호출할 수 있습니다. 직접
치명적인 오류: 개체에 대해 __clone() 메서드를 호출할 수 없습니다. - ...에서 대신 'clone $obj'를 사용하세요. Variable 구문 일관성 AST는 또한 다른 RFC에서 해결된 일부 구문 일관성 문제도 해결합니다. 제안: https:// wiki.php.net/rfc/uniform_variable_syntax.
Expression PHP5
# 🎜 🎜## 🎜🎜#$$foo['bar']['baz']

${$foo['bar']['baz']}

($$ foo)['bar']['baz']


$foo->$bar['baz']

#🎜🎜 #$foo ->{$bar['baz']}

($foo->$bar)['baz']

# 🎜🎜# $foo->$bar['baz']()$foo->{$bar['baz']}()

#🎜🎜#( $foo- >$bar)['baz']()#🎜🎜##🎜🎜##🎜🎜##🎜🎜#Foo::$bar['baz']()#🎜🎜##🎜🎜 #Foo: :{$bar['baz']}()#🎜🎜##🎜🎜#(Foo::$bar)['baz']()#🎜🎜##🎜🎜##🎜🎜## 🎜🎜# #🎜🎜# 전체적으로 이전 순서는 오른쪽에서 왼쪽이었지만 이제는 왼쪽에서 오른쪽이며 괄호가 동작에 영향을 주지 않는다는 원칙도 따릅니다. 이러한 복잡한 변수 작성 방식은 실제 개발 시 주의가 필요합니다. #🎜🎜##🎜🎜#관련 권장 사항: #🎜🎜##🎜🎜##🎜🎜#PHP 오류 에코 정보를 끄는 방법을 가르치는 5가지 방법#🎜🎜##🎜🎜##🎜🎜##🎜 🎜 ##🎜🎜#PHP 소스 코드의 FastCGI 프로토콜 분석#🎜🎜##🎜🎜##🎜🎜##🎜🎜##🎜🎜##🎜🎜#

위 내용은 PHP7의 새로운 기능 중 추상 구문 트리(AST)에 대한 일부 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.