[PHP-DEV] Zend Engine License in PHP source code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Today I sent 2 e-mails to lice...@zend.com, one from (signed), one from with the following content: = START EMAIL = Hello, I have found a few issues with the header we usually found in PHP's source code as well as with the license itself: +--+ | Zend Engine | +--+ | Copyright (c) Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is | | available through the world-wide-web at the following url: | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | lice...@zend.com so we can mail you a copy immediately. | +--+ Problem 1: The license is not available at the provided address. The "LICENSE" file under php source's Zend directory stipulates: "Copyright (c) 1999-2006 Zend Technologies Ltd. All rights reserved." Problem 2: Does it mean that the copyright isn't covering the last 15 years? Problem 3: Point #5 and #6 stipulates: 5. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes the Zend Engine, freely available at http://www.zend.com; 6. All advertising materials mentioning features or use of this software must display the following acknowledgment: "The Zend Engine is freely available at http://www.zend.com; However that is not correct, the Zend Engine is not freely available on Zend's website. What do you suggest to solve those issues? Kind regards, Patrick Allaert = END EMAIL = In both cases, I received the same direct error answer from distant mail server with: 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [DM3NAM02FT011.eop-nam02.prod.protection.outlook.com] This means that in addition to the 3 problems mentioned in the above e-mail, there are additional ones: Problem 4: There is no way to get a copy by e-mail as mentioned in the copyright header: "If you did not receive a copy of the Zend license and are unable to obtain it through the world-wide-web, please send a note to lice...@zend.com so we can mail you a copy immediately." Problem 5: There is no way to get a written permission from Zend as stipulated in the LICENSE file: " 3. The names "Zend" and "Zend Engine" must not be used to endorse or promote products derived from this software without prior permission from Zend Technologies Ltd. For written permission, please contact lice...@zend.com." I'm afraid this is material to make jokes from. What can we do to improve that situation? Sorry for bringing a non technical topic to this ML. Cheers, Patrick - -- - -Patrick -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.0.7 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAGBQJgw5vlACEJEBmfnf72/7r9FiEE8faSI4+8FmblpczUGZ+d /vb/uv1BEhAAl5QSWFqEx5No/ti9Jk9UYwRtzuwojD3oxuoNtcI/Bn5TB4c3 hf1ermFErQz9O6YRNnd3EJedgwJ/FpJJx7FWt1loqUuyoW1lr0qOGkuuqB1o ZCkMd9sJiHflEABUXFSgqPHjrZBv9eHGQ1eN1pL9yDrAvbNvWewhdJm0g/TC lfeDcKBJ+l0KG/npSBBin8FVofdclLRINLSP215jDvVRxbJDEjNyyAq7lNmm 4PEA+yRa8kb8IotEVqeu6SIDchir33oM50wWoT1nembQO3RtT+3r4iTILCsn ekpqFR95itDoIy/oaTXL0KOYXl5tCjl+4lo0FgUc3I+6VYu6qW88o8Bp6KIs mQVSq46WPDQCmaTK+ngba1JBkzpAGM3nGOgDaIJDZNrGV8RxerPchpM2FD5s uIMelKfKpgcOnBXJXdpZDcWLWC8snAAUpxf/8ypTyswxowCpsIa+aZjoZ7bb C1FxnDKG/HDA4hTOjVkyrgfmeq1BYCw55I63mXvqPsQ5L/4+kd82TpyrfwcS 1Qnq2Y39uvD4Dt11weKcCRl3qwlsjY5s5gzeThVDyyd0GjYSflndf7NPPtai BOvL/6CulnSWtBr5Tge3O74QmHOa3I6IZHrEyBbBU16c9el+6CYKdleAi3sv pYg0635Cy694eKlRrcxAG2YDFVa5vMCDoKU= =4ajl -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New in initializers
On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote: > Hi internals, > > I would like to propose allowing the use of "new" inside various > initializer expressions: https://wiki.php.net/rfc/new_in_initializers > > In particular, this allows specifying object default values for properties > and parameters, and allows the use of objects as attribute arguments. > > The RFC is narrow in scope in that it only adds support for "new". An > extension to other call kinds should be straightforward though. > > Regards, > Nikita Hi Nikita. What's the status of this RFC? Are you going to bring it to a vote, or is something else blocking it? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Partial Function Application, take 2
There's a couple of typos in the RFC, which Larry will fix when he has time. There was also a typo in patch, and a fault in patch. All fixed. pending tests, 3v4l won't update until tomorrow. Cheers Joe On Fri, 11 Jun 2021 at 13:02, Guilliam Xavier wrote: > Sorry, me again :s I have tested the examples from > https://wiki.php.net/rfc/partial_function_application on > https://3v4l.org/#focus=rfc.partials and several of them currently give an > error: > > - Ex 10: on the line `$c = stuff(?, ?, f: 3.5, ..., p: $point);` > => Fatal error: Named arguments must come after all place holders > (typo I guess, `$c = stuff(?, ?, ..., f: 3.5, p: $point);` is OK) > > - (Ex 11: no error but a typo: `'hi'` vs `'foo'`) > > - Ex 16: for the last call `(four(..., d: 4, a: 1))(2, 3);` > => Fatal error: Uncaught ArgumentCountError: four(): Argument #2 ($b) not > passed > (on the function definition line) > (`(four(..., d: 4, a: 1))(2, 3, 5, 6);` idem, > but `(four(..., d: 4, a: 1))(b: 2, c: 3);` throws an "Unknown named > parameter $b" Error on the call line) > (weird) > > - func_get_args() and friends: one the last line `$f(1, 2);` (after `$f = > f(?);`) > => Fatal error: Uncaught Error: too many arguments for application of f, 2 > given and a maximum of 1 expected > (can make sense, e.g. https://externals.io/message/114532#114554 ) > > - (Callable reference: no error but a typo: `$f` vs `$foo`) > > - Optimizations: on the line `$boo = $baz(4, ...);` > => Fatal error: Uncaught Error: too many arguments and or place holders for > application of Closure::__invoke, 1 given and a maximum of 0 expected > (`$boo = $baz(?);` throws the same error, > but `$boo = $baz(4);` throws a "not enough arguments for implementation of > foo, 4 given and exactly 5 expected" Error, > and `$boo = $baz(...);` makes the subsequent `$boo(5);` throw a "not enough > arguments ..." Error) > (weird, looks like `$bar = $foo(2, ...);` and/or `$baz = $bar(3, ...);` > dropped too many params) > > Regards, > > -- > Guilliam Xavier >
Re: [PHP-DEV] [VOTE] Deprecate autovivification on false
Hi Dmitry, Thanks for voicing your concerns. I have started writing implementation and it is definitely challenging for me, because I am not that experienced with PHP internals yet. https://github.com/php/php-src/pull/7131 Almost every implementation requires some amount of work. I would like to ask you for more details on why you think this particular change is infeasible. Do you see any problems that the implementation of this deprecation message would cause? Would it be better to wait for PHP 9.0 and remove it without deprecation? As I see it, we already have an error for other scalar types. For false, we will just need to throw a deprecation notice in the same places. It doesn't require a major rewrite of PHP engine from what I can tell. Regards, Kamil
Re: [PHP-DEV] [RFC] Partial Function Application, take 2
Sorry, me again :s I have tested the examples from https://wiki.php.net/rfc/partial_function_application on https://3v4l.org/#focus=rfc.partials and several of them currently give an error: - Ex 10: on the line `$c = stuff(?, ?, f: 3.5, ..., p: $point);` => Fatal error: Named arguments must come after all place holders (typo I guess, `$c = stuff(?, ?, ..., f: 3.5, p: $point);` is OK) - (Ex 11: no error but a typo: `'hi'` vs `'foo'`) - Ex 16: for the last call `(four(..., d: 4, a: 1))(2, 3);` => Fatal error: Uncaught ArgumentCountError: four(): Argument #2 ($b) not passed (on the function definition line) (`(four(..., d: 4, a: 1))(2, 3, 5, 6);` idem, but `(four(..., d: 4, a: 1))(b: 2, c: 3);` throws an "Unknown named parameter $b" Error on the call line) (weird) - func_get_args() and friends: one the last line `$f(1, 2);` (after `$f = f(?);`) => Fatal error: Uncaught Error: too many arguments for application of f, 2 given and a maximum of 1 expected (can make sense, e.g. https://externals.io/message/114532#114554 ) - (Callable reference: no error but a typo: `$f` vs `$foo`) - Optimizations: on the line `$boo = $baz(4, ...);` => Fatal error: Uncaught Error: too many arguments and or place holders for application of Closure::__invoke, 1 given and a maximum of 0 expected (`$boo = $baz(?);` throws the same error, but `$boo = $baz(4);` throws a "not enough arguments for implementation of foo, 4 given and exactly 5 expected" Error, and `$boo = $baz(...);` makes the subsequent `$boo(5);` throw a "not enough arguments ..." Error) (weird, looks like `$bar = $foo(2, ...);` and/or `$baz = $bar(3, ...);` dropped too many params) Regards, -- Guilliam Xavier
Re: [PHP-DEV] [VOTE] Deprecate autovivification on false
On Fri, Jun 11, 2021 at 12:19 PM Claude Pache wrote: > > > > > I wouldn't care about disabling autovivification on false, but I vote > "No", > > because I'm against the deprecation. > > > Do you mean, you wouldn’t care if it went directly from “working without > notice” in PHP 8.0 to “fatal error” in PHP 8.1? That would be extremely > hostile for large code bases in their upgrading process, as it is in > general not a feature that can be checked and corrected statically. > The RFC doesn't provide implementation, and I see that the implementation of this deprecation may be not as simple as expected. Thanks. Dmitry. > —Claude
Re: [PHP-DEV] [VOTE] Deprecate autovivification on false
> > I wouldn't care about disabling autovivification on false, but I vote "No", > because I'm against the deprecation. Do you mean, you wouldn’t care if it went directly from “working without notice” in PHP 8.0 to “fatal error” in PHP 8.1? That would be extremely hostile for large code bases in their upgrading process, as it is in general not a feature that can be checked and corrected statically. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate autovivification on false
hi, I wouldn't care about disabling autovivification on false, but I vote "No", because I'm against the deprecation. Thanks. Dmitry. On Wed, Jun 9, 2021 at 11:24 PM Kamil Tekiela wrote: > Hi Internals, > > I have limited the RFC to disabling autovivification on false only, which > was the initial scope of the RFC. The only two possible cases remaining > will be undefined and null. After what Tyson Andre clearly explained, null > is commonly used and leads to many more complex situations. > > I have opened voting on https://wiki.php.net/rfc/autovivification_false > which will end on 2021-06-23T20:00:00Z > > Link to the discussion thread: https://externals.io/message/114595 > > The implementation is pending, but if someone wants to suggest one, please > feel free. > > Regards, > Kamil >
