On 26.04.2022 at 06:02, chopins xiao wrote:
> 0. when dot object opeator is enable, use small sign and add sign [<+] be
> equivalent to [.] for string concat mark.
> compatibility is achieved through configuration switches.
> syntax :
> >>> $a = 'str0';
> >>> $a .= 'str1' <+ 'str2' <+ 'str3' <+ $str_var <+ strcall();
> the concat equal sign[.=] not change
>
> 1. use dot mark[.] same with [->]
> syntax:
> >>> $a = new stdClass;
> >>> $a.b =1; same with $a->b = 1 when dot object opeator is
> enable in php.ini
> >>> $a.get(); same with $a->get() when dot object opeator is
> enable in php.ini
>
> 2. colon [:] same with [=>] in array declaration statement
> syntax:
> >>> $a = [ 'b' : 1, 'c' : 3 ]; same with $a = ['b'=>1, 'c' => 3]
>
> 3. another class declaration statement, cant not use [extends] and
> [implement] keyword
> syntax:
> >>> class Objects(ParentClass): Interface1,Interface2 {}
> same with
> >>> class Objects extends ParentClass implement
> Interface1,Interface2 {}
>
> anonymous class
> >>> $obj = new($arg1,$arg2) class(ParentClass) : implement
> Interface1,Interface2 {}
> same with
> >>> $obj = new class($arg1,$arg2) extends ParentClass implement
> Interface1,Interface2{}
>
> 5. another class method declaration statement, omit [function] keyword is
> allowable
> syntax:
> >>> public method_name($args) {}
> same with
> >>> public function method_name($args) {}
>
> 6. restriction public magic method synax sugar, omit [public][function]
> keywords and duoble underline[__] is allowable, only __get() __set()
> __call() __callStatic() __toString() __sleep() __wakeup() __serialize()
> __unserialize() is availabled
> syntax:
> >>> class A {
> >>> get() {
> >>> }
> >>> call() {
> >>> }
> >>> }
> same with:
> >>> class A {
> >>> public function __get() {
> >>> }
> >>> public function __call() {
> >>> }
> >>> }
>
> The implement and syntax see:
> https://github.com/chopins/php-src/blob/fast_grammar/FastSyntax.md
In my opinion, it is generally a bad idea to support different syntax
based on an INI setting. This easily leads to confusion for those
reading the code.
I don't see much point in these "simplifications" anyway, except maybe
for the shorter array literals. Note though, that there has been RFC[1]
about a similar syntax, but that had been declined.
[1] <https://wiki.php.net/rfc/bare_name_array_literal>
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php