php-annotated-monthly-march-2019

Posted on 2019-03-19 Edited on 2019-03-24 Disqus:

Php_annotated_monthly 이미지

JetBrains에서 제공하는 월간 PHP Annotated Monthly 3월호입니다.

이 중에서 몇 가지 제 취향껏 골라 그 안의 내용도 좀 뒤져보고 개발새발 번역해서 소개합니다.

News & Releases

PHP

Xdebug 2.7.0

https://xdebug.org/#2019_03_06

오래 기다리셨어요. 이제 7.3을 지원합니다.

ircmaxell/php-compiler

https://github.com/ircmaxell/php-compiler

Anthony Ferrara가 만든 PHP compiler를 소개합니다. PHP도 (JVM과는 다르지만) VM에서 돌아가는데, 이 컴파일러는 PHP7.4부터 지원될 FFI를 활용해서 VM 위에서 돌지 않도록 바로 native machine code를 생성해서 실행가능한 코드(standalone binary)를 만들어 준다고 합니다.

링크에 들어가 보시면, 세가지 컴파일 모드를 소개하는데, PHP로 만든 첫번째 모드는 엄청 느리고 VM에서 도는 버전이고, 두번째 JIT(Just In Time) 모드에선 machine code를 생성해서 실행하는데 PHP7.4 버전보다 실행은 빠르지만 PHP에서 컴파일 되느라 컴파일 속도가 너무 느렸다고 합니다. 매번 실행할 때마다 컴파일을 새로 한다는군요. 마지막 compile 버전에선 아예 실행 가능한 바이너리로 만들어서 이론적으로는 native C 만큼의 속도가 나왔다고 합니다.

아직은 PoC(Proof of Concept)라서 매우 제한적으로 지원하지만 희망찬 미래를 보여줬다고 평가하는군요.

무궁무진한 미친 짓을 할 수 있답니다.

PHP Internals

The proposal to abolish 50% threshold on voting

https://wiki.php.net/rfc/abolish-narrow-margins

RFC 프로세스가 바뀌었다고 합니다.

두 카테고리로 나뉘었고

PHP에 변화를 주는 것
정책 문서를 변경하거나 생성하는 것

통과 되려면 투표로 2/3 이상의 승인을 받아야 합니다.

overview of the unaccepted RFCs

https://github.com/Danack/RfcCodex

사람들이 관심이 많지만 아직 받아들여지지 않은 RFC가 어떻게 되고 있는지 정리한 글입니다.

아직 논의 중인 것

어노테이션Annotations
- 몇몇 사람은 여전히 어노테이션을 싫어하고
- 이미 주석을 통한 어노테이션을 쓰는 사람들은 RFC가 자신들의 use case에 충분하지 않아 좀 더 개선하길 바람
더 간략한 클로저 문법Briefer closure syntax
- 아주 큰 혜택이 없기 때문에 몇몇 사람들은 그다지 원하지 않는다
- JavaScript 같은 경우는 자연스럽게 parameter를 상위 scope으로부터 받을 수 있지만 PHP에선 명시적으로 넣어줘야 하는데, 어떤 문법을 써야 할까?
- 리턴 타입도 결정해야 하는데, 어떤 문법을 사용해야 할까?
클래스 scope 개선Class scoping improvements
- 같은 패키지 내에만 공개해야할 메소드도 public으로 제공해야 하는 문제를 개선해야 함
- 마땅히 구현할 만한 방법이 없음
- C++의 friendship도 적당하지 않음
Consistent callables
- Callable을 일관성있게 변경하는 RFC가 등록되어 있음
Enums
- enum을 어떻게 정의할 것인가에 대한 다른 관점이 있음
- Draft RFC가 등록되어 있으나 시간과 에너지를 쏟을 사람이 없음. 누군가 (이 RFC를 올린) Levi나 Bob에게 몇 달 치 월급을 주면 가능할 것이라고…
Generics
- 제네릭의 필요성은 놀랄 만큼 일치하고 있지만 구현하기가 어렵다(인터프리터 방식에서 오는 한계인 것으로 보입니다)
- 정말 제네릭이 꼭 필요하다면 https://preprocess.io/ 를 활용할 수는 있다
Method overloading
- PHP는 정적 타입 언어와 달리 런타임에 타입이 변할 수 있기 때문에 쉽지 않다
- 성능 문제도 발생할 수 있다
- 메소드 오버로딩이 왜 필요한가에 대한 명확한 근거가 없다
- 정 원하면 이를 대체할 방법도 알려줍니다
Standardise core library
- Core 라이브러리 함수의 비일관성(함수명, 파라미터…)
- 모든 비일관성이 전부 비일관적인 건 아니다(다 이유가 있다는 뜻)
- 기존 수많은 코드를 전부 변경할 수도 없고, 누구도 긴 시간동안 수많은 alias를 유지하고 싶어하지도 않음
- 관련 링크
  - https://wiki.php.net/rfc/consistent_function_names
  - http://phpsadness.com/sad/9
Union types
- parameter나 return type에 여러 타입을 전달/리턴할 수 있도록 하는 union_types RFC
- 사람들이 타입시스템에 익숙하지 않은 것이 걸림돌이라고 하는데…글쎄요

앞으로 할 것

Async
Structs
Explicit defaults

[RFC] Consistent type errors for internal functions

https://wiki.php.net/rfc/consistent_type_errors

이 RFC가 accepted 되어서 PHP 8 부터는 모든 내장 함수에서 잘못된 argument 타입이 들어오면 TypeError를 발생시킵니다.

[RFC] Weak References

https://wiki.php.net/rfc/weakrefs

PHP 7.4부터 WeakReference가 도입됩니다. 가비지 컬렉터로 객체가 파괴되는 것을 막지 않으면서 객체에 대한 참조를 유지할 수 있습니다.

[RFC] Saner string to number comparisons

https://wiki.php.net/rfc/string_to_number_comparison

Nikita Popov가 PHP 8을 목표로 좀 더 납득할 만한 문자열 - 숫자 비교 연산을 제안했습니다.

php-numeric-string-comparison

이에 대한 많은 논쟁이 있는 것으로 보입니다만, 그 동안은 PHP 7.4에서 Warning을 받을 수 있습니다.

[RFC] Locked Classes

https://wiki.php.net/rfc/locked-classes

새로운 클래스용 키워드인 locked를 제안했군요. property를 동적으로 할당할 수 없게 합니다.

Allow throwing from __toString()

http://news.php.net/php.internals/104535

Nikita가 __toString method에서는 exception을 throw할 수 없게 되어 있는데, 이를 가능하게 하는 PR이 올라왔습니다. PHP sadness에 있던 것 중 하나였죠.

[RFC] Arrow Functions 2.0

https://wiki.php.net/rfc/arrow_functions_v2

(위 Briefer closure syntax에서도 언급했던) 짧은 클로저 문법에 관한 세번째 시도입니다. 이번엔 Nikita, Bob, Levi가 함께 붙었습니다!

[RFC] Generator comprehensions

https://wiki.php.net/rfc/comprehensions

Generator를 편하게 사용할 수 있는 draft RFC입니다.

$a = [1, 2, 3];
$mul = 3;
$c = [ for $a as $v yield $mul * $v ];

PHP Internals News: Episode 1

https://derickrethans.nl/phpinternalsnews-01.html

Xdebug의 author인 Derick Rethans가 새로운 팟캐스트를 시작했습니다. 첫 에피소드는 Nikita Popov와 함께 한 PHP Internals News랍니다.

이런 내용을 이야기 했군요.

RFC Watch — a web site to keep an eye on RFC voting progress
RFC: Permit trailing whitespace in numeric strings
RFC: JIT

기타 읽을 만한 글

Moving away from magic — or: why I don’t want to use Laravel anymore

https://medium.freecodecamp.org/moving-away-from-magic-or-why-i-dont-want-to-use-laravel-anymore-2ce098c979bd

라라벨에서 너무 많은 것을 자동으로 처리해주기 때문에 라라벨을 떠난다는 글입니다.

Eloquent ORM은 Active record 패턴을 사용하고 개발자가 코드를 덜 쓰기를 바라길 원하는데, 이런 특성이 코드를 이해하거나 정적 분석 혹은 IDE를 활용하기에도 좋지 않고, 계속 메소드를 추가하게 되어 단일 책임 원칙을 위반하도록 유도 합니다
Global 헬퍼 함수는 더 좋은 방식으로 대체할 수 있는 방법이 있음에도 단지 사용하기 쉬운 방법을 제공하기 위해 global namespace를 더럽히고 설계면에서 희생해야 합니다. 5.8에서는 일부 헬퍼 함수가 제거되어 다행이지만, 모든 헬퍼 함수를 사용하지 않게 안내해야 합니다
Facade도 실제론 static 메소드가 아닌 어떤 메소드에 쉽게 접근할 수 있는 좋은 툴 같지만 모든 걸 magic method에 전달하면서 복잡도만 증가했습니다. IDE의 지원을 받기 어려운 문제도 IDE helper package를 통해 해결할 수 있지만, 애초에 필요가 없는 라이브러리입니다. 게다가 사실 이건 Gang of Four에서 말하는 Facade 디자인 패턴도 아닙니다. 차라리 static service locators라고 불러야 합니다.
모든 것을 가능한 한 쉽게 만드는 Laravel의 접근법은 좋습니다. 그러나 앱이 성장할 수록 관리하기 어렵습니다. 나는 IDE 지원, 더 강한 타이핑, 실제 객체, 그리고 좋은 엔지니어링을 선호합니다. 더 작은 앱을 쓰고 싶을 때 Laravel로 돌아갈 수도 있습니다.
요점은 Laravel의 잘못이 아닙니다. 내 요구 사항에 더 잘 맞는 툴킷으로 전활할 것입니다. 다른 프레임 워크와 도구는 기본 설계가 더 좋고 마법이 적습니다.