#language-design

[Pre-RFC] Scalar object methods (with a working implementation)

Bài thảo luận đề xuất bổ sung phương thức đối tượng cho các kiểu scalar (số, chuỗi) trong PHP, cho phép gọi trực tiếp như $str->trim() hay (3)->pow(2). Phương pháp này sử dụng cơ chế dispatch tĩnh, chuyển đổi thành lời gọi static tới các lớp nội bộ mà không thêm opcode mới, nhưng vấp phải phản đối về phạm vi áp dụng hạn chế do mô hình biên dịch theo file của PHP và nguy cơ phá vỡ công cụ phân tích tĩnh.

Lập trình viên nên đọc bài này để hiểu cách PHP đang thảo luận về cách mở rộng tính năng gọi phương thức trực tiếp trên giá trị nguyên thủy (scalar) như $str->trim() mà vẫn đảm bảo hiệu suất và tính bảo mật thông qua cơ chế phân tán compile-time.

Programming Languages Are Authoring Tools for Platforms

Tác giả cho rằng ngôn ngữ lập trình chính là công cụ sáng tạo (authoring tools) cho các nền tảng (platforms).

Lập trình viên nên đọc bài này để hiểu cách ngôn ngữ lập trình không chỉ là công cụ thực hiện mã mà còn là khung xây dựng và định nghĩa nền tảng riêng của dự án, giúp tối ưu hóa hiệu suất, tính mở rộng và tương thích với tương lai.

Python’s Most Confusing Features Actually Make Perfect Sense

Python sở hữu những tính năng gây bối rối nhưng thực chất lại hợp lý nhờ thiết kế nhất quán và triết lý ngôn ngữ rõ ràng.

Nếu bạn đang gặp khó khăn với những đặc điểm Python như vòng lặp while thay vì do...while, quản lý ngoại lệ với try-except hoặc tính chất đa hình, bài viết sẽ giúp bạn hiểu rõ nguyên lý thiết kế của ngôn ngữ, từ đó tránh nhầm lẫn và sử dụng hiệu quả hơn.

GitHub - jbwinters/jacquard-lang: Jacquard is a small programming language designed for a regime in which most code is written by machine-learning models and reviewed by people.

Jacquard is a small programming language designed for a regime in which most code is written by machine-learning models and reviewed by people. - jbwinters/jacquard-lang

Class Extension

A PHP internals mailing list thread where Holly Schilling proposes adding class extensions to PHP, inspired by Swift's extension syntax, implemented in a 2-phase approach. Michael Morris questions the value of the feature, arguing that PHP's existing inheritance and traits already cover what Swift-style extensions provide.

Class Extension

Holly Schilling đề xuất bổ sung tính năng class extension cho PHP, lấy cảm hứng từ cú pháp extension của Swift, và khẳng định đã chứng minh khả thi thông qua cách triển khai 2 giai đoạn. Cô đang thăm dò sự quan tâm của cộng đồng trước khi tiếp tục phát triển.

Lập trình viên PHP nên theo dõi đề xuất này để hiểu cách mở rộng tính năng của các lớp hiện có mà không cần thay đổi mã nguồn gốc, giúp tối ưu hóa hiệu suất và tái sử dụng code theo phong cách Swift, từ đó có thêm nhiều lựa chọn trong việc phát triển ứng dụng.

[Pre-RFC] Scalar object methods (with a working implementation)

A pre-RFC discussion on the PHP internals mailing list proposes adding scalar object methods to PHP, allowing calls like $str->trim() or (3)->pow(2) directly on scalar values. The approach dispatches only on receivers the compiler can statically guarantee are scalar at compile time, rewriting method calls to ordinary static calls into internal backing classes with zero new opcodes and negligible performance overhead. The proposal includes two independent votes: scalar methods on guaranteed receivers, and optionally typed local variables. Community responses raise objections including that compile-time-only dispatch covers very little real-world code due to PHP's per-file compilation model, that hiding backing classes breaks static analysis tooling, and that a broader extension functions mechanism (à la Kotlin/C#) would be preferable to a curated fixed method set.

[Pre-RFC] Scalar object methods (with a working implementation)

Đề xuất bổ sung phương thức đối tượng cho các kiểu scalar (số, chuỗi) trong PHP, cho phép gọi trực tiếp như $str->trim() hay (3)->pow(2). Cách tiếp cận này chỉ hoạt động khi trình biên dịch xác định được kiểu scalar tại thời điểm biên dịch, chuyển đổi thành lời gọi static tĩnh mà không tốn thêm opcode hay ảnh hưởng hiệu suất.

Lập trình viên nên đọc để hiểu cách PHP có thể nâng cấp tính linh hoạt của ngôn ngữ bằng cách tích hợp các phương thức đối tượng vào giá trị nguyên thủy—tránh rủi ro của việc mở rộng quá nhiều và tối ưu hóa hiệu suất cho các trường hợp sử dụng thực tế.

[Pre-RFC] Scalar object methods (with a working implementation)

Một đề xuất trên danh sách thư PHP internals đề xuất bổ sung phương thức đối tượng cho kiểu scalar (như $str->trim() hay (3)->pow(2)), sử dụng cơ chế gọi tĩnh nội bộ mà không tạo opcodes mới. Đề xuất này vấp phải phản đối do chỉ hoạt động ở thời điểm biên dịch (không hỗ trợ autoload), gây khó khăn cho công cụ phân tích tĩnh, và tạo ra cú pháp thứ ba cạnh tranh với hàm thủ tục hiện có. Larry Garfield đề xuất giải pháp tổng quát hơn là extension functions.

Lập trình viên nên đọc để hiểu cách PHP đang thảo luận về một giải pháp mới để mở rộng tính năng gọi phương thức trực tiếp trên giá trị số hoặc chuỗi mà không cần chuyển đổi thành đối tượng, cùng những thách thức kỹ thuật và ý kiến phản đối từ cộng đồng về tính ổn định và tương thích.

[Pre-RFC] Scalar object methods (with a working implementation)

Đề xuất bổ sung phương thức gọi trực tiếp trên giá trị scalar (như $str->trim(), (3)->pow(2)) trong PHP đang được thảo luận trên mailing list nội bộ, sử dụng cơ chế dispatch tĩnh tại thời điểm biên dịch nhằm tránh overhead. Triển khai thử nghiệm trên PHP 8.6-dev cho thấy không gây xung đột, nhưng nhận nhiều phản đối về phạm vi áp dụng hạn chế, tác động tới công cụ phân tích tĩnh, và đề xuất thay thế bằng extension functions (như Kotlin/C#) thay vì giới hạn phương thức sẵn có.

Lập trình viên nên đọc để hiểu cách PHP 8.6 đang thử nghiệm cách mở rộng tính năng gọi phương thức trực tiếp trên giá trị số hoặc chuỗi mà không cần biến, giúp tối ưu hóa hiệu suất và mở rộng khả năng sử dụng của ngôn ngữ mà không cần thay đổi cơ sở hạ tầng mới.

[Pre-RFC] Scalar object methods (with a working implementation)

A pre-RFC discussion on the PHP internals mailing list proposes adding scalar object methods to PHP, allowing calls like $str->trim() or (3)->pow(2) directly on scalar values. The approach dispatches only on receivers the compiler can statically guarantee are scalar at compile time, rewriting method calls to ordinary static calls into internal backing classes with zero new opcodes and negligible performance overhead. The proposal includes two separable votes: scalar methods on guaranteed receivers, and typed local variables. A working implementation on PHP 8.6-dev is provided with BC impact analysis showing zero breakage across 173k+ Packagist files. Objections raised include the limited practical reach of compile-time-only dispatch (cross-file autoloaded classes won't qualify), tooling visibility issues with NUL-prefixed internal backing classes, and the broader concern that coexisting procedural and method-call syntax adds complexity without replacing anything.

[Pre-RFC] Scalar object methods (with a working implementation)

A pre-RFC discussion on the PHP internals mailing list proposes allowing method calls directly on scalar values (e.g. $str->trim(), (3)->pow(2)). The approach dispatches only on receivers the compiler can syntactically guarantee are scalar at compile time, rewriting the call to an ordinary static call into an internal backing class — adding zero new opcodes and leaving untyped code unchanged. The proposal includes two separable votes: scalar methods on guaranteed receivers, and scalar-typed local variables. A working implementation on PHP 8.6-dev is provided with performance benchmarks, JIT correctness verification, and a BC scan of 173k+ Packagist files showing zero breaking changes. Objections raised include: the compile-time-only guarantee covers very little real-world code due to PHP's single-file compilation model (cross-file autoloaded classes won't qualify), tooling/static-analyser disagreement with the compiler, and the broader concern that coexisting procedural and method-call forms add complexity without replacing anything.

[Pre-RFC] Scalar object methods (with a working implementation)

Đề xuất pre-RFC giới thiệu phương thức đối tượng cho các kiểu vô hướng (scalar) trong PHP, cho phép gọi phương thức trực tiếp trên giá trị như $str->trim() hay (3)->pow(2). Cách tiếp cận này chỉ xử lý các đối tượng chắc chắn là kiểu vô hướng tại thời điểm biên dịch, chuyển đổi thành các lớp nội bộ mà không ảnh hưởng đến hiệu suất. Có hai phần độc lập để bỏ phiếu: phương thức trên kiểu vô hướng đảm bảo và biến cục bộ có kiểu vô hướng. Bản triển khai thử nghiệm trên PHP 8.6-dev cho thấy không có thay đổi phá vỡ trong hơn 173k tệp Packagist.

Lập trình viên nên đọc để hiểu cách PHP 8.6+ có thể mở rộng khả năng gọi phương thức trực tiếp trên giá trị nguyên thủy (scalar) như $x->toUpperCase() mà không cần thay đổi mã nguồn hiện tại, đồng thời đánh giá tác động về hiệu suất và công cụ phân tích static.

[php-src] PR #20903: GH-10497 (const obj->prop write)

A PHP internals mailing list thread discussing RFC const_object_property_write (PR #20903), which proposes allowing property writes on objects referenced by PHP constants. Currently, writing to CONST_OBJ->prop raises a 'Cannot use temporary expression in write context' error even though the operation mutates the object, not the constant binding. The RFC has evolved through multiple versions: v0.1 included array/dim writes (which were controversial due to silent no-op behavior), v0.2 scoped out array writes to focus only on object property writes, and v0.3 extended coverage to class constants in addition to global constants. A notable edge case is that enum cases are class constants, so writes to readonly enum case properties now raise a runtime readonly-property Error instead of a compile-time error. The RFC targets PHP 8.6 and requires a 2/3 majority vote.

[RFC] Primary Constructors

A PHP internals mailing list thread discussing a proposed RFC for Primary Constructors in PHP. The RFC proposes a new syntax allowing class properties and constructor parameters to be declared at the top of the class definition, similar to Kotlin or C# primary constructors. Key debate points include: whether primary constructor bodies should be supported (the RFC excludes them), compatibility with readonly classes and property hooks, anonymous class support (deferred to future scope), and whether the limited scope of the feature justifies adding new syntax. The RFC author argues 30-70% of real-world PHP classes could benefit even without bodies, while critics argue the feature is too restricted to be worth the added complexity.

[php-src] PR #20903: GH-10497 (const obj->prop write)

PR #20903 đề xuất cho phép ghi thuộc tính vào đối tượng được tham chiếu bởi hằng PHP (const), khắc phục lỗi "Cannot use temporary expression in write context" khi gán CONST_OBJ->prop = value. RFC đã trải qua nhiều phiên bản sửa đổi, mở rộng từ mảng sang hằng lớp (class constants) và enum, sắp tới sẽ bỏ phiếu chính thức cho PHP 8.6 với yêu cầu 2/3 phiếu thuận.

Lập trình viên cần đọc để hiểu cách PHP 8.6 sẽ mở rộng khả năng tương tác với các thuộc tính của đối tượng thông qua các hằng số, giúp tối ưu hóa mã nguồn cho các trường hợp sử dụng enum và đối tượng liên kết chặt chẽ với hằng số.

[RFC] Case sensitive PHP

A PHP internals mailing list thread discussing a proposed RFC to make PHP fully case-sensitive. The RFC author Jorg Sowa revived the discussion, collecting points from previous debates. Supporters argue it would simplify the Zend engine, static analyzers, and LSPs by removing the need for identifier normalization passes, and would make PHP consistent with other languages. Opponents question the practical benefit, noting IDEs already enforce correct casing, and raise concerns about PHP's own inconsistent built-in naming (DateTime vs PDO vs mysqli). A key concern is that making PHP case-sensitive without first standardizing the standard library's naming conventions would create a 'casing salad' problem. The thread ends with the RFC author announcing he is abandoning the RFC due to low chances of it passing.

[RFC] Case sensitive PHP

A PHP internals mailing list thread discussing a proposed RFC to make PHP fully case-sensitive. Currently, PHP treats function names, class names, and method names case-insensitively (e.g., STRLEN() works the same as strlen()). The RFC author Jorg Sowa proposes deprecating case-insensitive behavior in a current PHP version and promoting it to an error in PHP 9.0. Supporters argue it simplifies the engine, removes the need for identifier normalization passes, benefits static analyzers and LSPs, and aligns PHP with most other languages. Opponents question the practical benefit, raise concerns about PHP's own inconsistent built-in naming conventions (DateTime vs PDO vs mysqli), and worry about breaking dynamic method calls. The RFC author acknowledges the core real-world motivation is autoloading portability across case-sensitive and case-insensitive file systems.