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