Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Martin, On Mon, Apr 15, 2019, 5:08 PM Nikita Popov wrote: > On Mon, Apr 15, 2019 at 11:51 AM Köditz, Martin > wrote: > > > Hello everybody, > > > > I want to give you the general state of the Firebird driver. At the end > of > > January, I agreed to continue developing the Firebird driver as a > > maintainer. In this regard, I first took care of getting familiar with > the > > code and an important bug (# 72175). > > > > Obviously, this information has not got through to the PHP community for > a > > variety of reasons. Unfortunately, the project seems to be pulled away by > > the vote to remove the driver underfoot. > > > > It would be nice if someone could agree with me on the further steps > > regarding further development. I particularly need help with the > following > > points: > > 1. How will I be deposited as a maintainer? > > > 2. Who has commit rights for changes? > > 3. How are changes in the documentation checked in? Here are my changes > > have not been committed for years. > > 4. Where are the current development guidelines? I have an old book, but > > it does not seem to reflect the current quality standards. > > > > Maybe it's to late. But maybe we (the Firebird and the PHP community) can > > continue on a common path. > > > > Hello Martin, > > The vote currently under way shouldn't change much for you: It mainly means > that the code of the extension will be moved into a new repository and that > the extension has to be installed using "pecl install interbase" instead of > "./configure --with-interbase". > > Unless you already have one, please request a PHP git account at > https://www.php.net/git-php.php. Once it is approved you will be granted > access to the ext/interbase extension in php-src, as well as the new PECL > repository for the extension once the move is completed. You can then > commit changes using git via git.php.net. You can also use github and upload releases in pecl.php.net. best, Pierre
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Martin, On Mon, 15 Apr 2019 at 10:50, Köditz, Martin wrote: > I agreed to continue developing the Firebird driver as a maintainer. As mentioned previously, possibly the first thing you should do is to make clear if you're maintaining it as something that is compatible with Firebird, or whether you are continuing the compatibility with InterBase. The two pieces of software have different capabilities[*]. You seem to be interested in maintaining it for Firebird, but the extension is currently called 'InterBase'. Having the supported DB change silently is quite a surprising thing to happen. Nikita Popov wrote: > as well as the new PECL > repository for the extension once the move is completed. Will that include mirroring to a github repository? Martin, either way I would recommend setting up a github repo to use in your workflow somewhere, as it is much easier for people to collaborate over (and can have things like TravisCI integration) more easily that PHP's git account can. And a Github repo is probably a better place to discuss plans for future support than PHP's bug tracker. cheers Dan Ack [*] https://ib-aid.com/en/articles/differences-between-firebird-and-interbase/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
Den 2019-04-15 kl. 13:48, skrev Benjamin Morel: Even though I was originally hoping for something closer to JS syntax, considering Nikita's summary it looks like the best contender is still fn(), as originally proposed. At least it looks like a function indeed, to the uninitiated. So FWIW, I think that a vote for the fn() syntax only still makes sense. The risk with the 2 or 3 options is never being able to reach a concensus: is a relative majority or an absolute majority for one of the syntaxes acceptable, or are you required by the RFC process to get a 2/3 majority for this vote as well? If so, considering the discussion so far, I think this will be hard to achieve with 2 choices, let alone with 3. - Ben If it lands in a secondary three way vote I would assume it's the vote getting the most votes. Otherwise the RFC could land in a limbo, getting yes on feature but no on syntax. Good to get assumption confirmed though... r//Björn L -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
> On 14 Apr 2019, at 23:52, Nikita Popov wrote:
>
> On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
>
>> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
>>
>>> Hi internals,
>>>
>>> Motivated by the recent list comprehensions RFC, I think it's time we
>>> took another look at short closures:
>>>
>>> https://wiki.php.net/rfc/arrow_functions_v2
>>>
>>> This is based on a previous (withdrawn) proposal by Levi & Bob. It uses
>>> the syntax
>>>
>>>fn($x) => $x * $multiplier
>>>
>>> and implicit by-value variable binding. This example is roughly
>>> equivalent to:
>>>
>>>function($x) use($multiplier) { return $x * $multiplier; }
>>>
>>> The RFC contains a detailed discussion of syntax choices and binding
>>> modes.
>>>
>>> Regards,
>>> Nikita
>>>
>>
>> Heads up: I plan to start voting on this RFC tomorrow if nothing new comes
>> up.
>>
>> Most of the discussion was (as expected) about the choice of syntax.
>> Ultimately I think there are many reasonable choices we can make here, but
>> we should stick to a specific proposal for the purposes of the RFC vote.
>> None of the given arguments convinced me that some other syntax is
>> *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a
>> matter of some choices being slightly better in one case and slightly worse
>> in another. My personal runner-up would be \($x, $y) => $x*$y, but I
>> suspect that there are some people who are more strongly biased against
>> "sigil salad" than I am...
>>
>> Nikita
>>
>
> So, there's been quite a bit of extra discussion here... unfortunately I
> can't say that it really clarified anything, we're still circling around
> different syntax choices, with the main contenders being fn, \ and ==>.
>
> fn($x) => $x
> fn($x, $y) => $x*$y
>
> \$x => $x
> \($x, $y) => $x*$y
>
> $x ==> $x
> ($x, $y) ==> $x*$y
>
> I think the main qualities of these possibilities are:
>
> * Implementation complexity: fn and \ are easy, ==> is hard (lexer hack).
> * Availability of reduced syntax: \ an ==> have a special single-argument
> syntax, fn doesn't.
> * Obviousness/readability: fn and ==> are obvious, while \ is not.
> Especially \$x => $x looks quite obscure to the uninitiated (is that a
> variable escape, like it would be in strings?)
>
> At this point I'm considering to either a) move forward with fn() as the
> choice I'd consider most likely to gather a consensus or b) have a
> secondary three-way vote between these three syntax choices.
>
> Nikita
As someone without voting rights (and thus you can take this with a grain of
salt), given what you’ve highlighted I believe your option (a) is the obvious
one:
You said yourself, that `==>` is a more complex/hard implementation (which is
bad) and that `\` is non obvious/obscure, and (IMO) it’s worse as far as
readability goes.
As I’ve said before, I expect to use this feature (if it passes) very little if
at all, but I still appreciate that `fn()...` keeps reasonably-familiar/obvious
syntax, because even if I choose not to write using this feature, I’ll
invariably have to read someone else’s code that does use it.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
Even though I was originally hoping for something closer to JS syntax, considering Nikita's summary it looks like the best contender is still fn(), as originally proposed. At least it looks like a function indeed, to the uninitiated. So FWIW, I think that a vote for the fn() syntax only still makes sense. The risk with the 2 or 3 options is never being able to reach a concensus: is a relative majority or an absolute majority for one of the syntaxes acceptable, or are you required by the RFC process to get a 2/3 majority for this vote as well? If so, considering the discussion so far, I think this will be hard to achieve with 2 choices, let alone with 3. - Ben
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
Den 2019-04-14 kl. 18:52, skrev Nikita Popov:
On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote:
On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote:
Hi internals,
Motivated by the recent list comprehensions RFC, I think it's time we
took another look at short closures:
https://wiki.php.net/rfc/arrow_functions_v2
This is based on a previous (withdrawn) proposal by Levi & Bob. It uses
the syntax
fn($x) => $x * $multiplier
and implicit by-value variable binding. This example is roughly
equivalent to:
function($x) use($multiplier) { return $x * $multiplier; }
The RFC contains a detailed discussion of syntax choices and binding
modes.
Regards,
Nikita
Heads up: I plan to start voting on this RFC tomorrow if nothing new comes
up.
Most of the discussion was (as expected) about the choice of syntax.
Ultimately I think there are many reasonable choices we can make here, but
we should stick to a specific proposal for the purposes of the RFC vote.
None of the given arguments convinced me that some other syntax is
*strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a
matter of some choices being slightly better in one case and slightly worse
in another. My personal runner-up would be \($x, $y) => $x*$y, but I
suspect that there are some people who are more strongly biased against
"sigil salad" than I am...
Nikita
So, there's been quite a bit of extra discussion here... unfortunately I
can't say that it really clarified anything, we're still circling around
different syntax choices, with the main contenders being fn, \ and ==>.
fn($x) => $x
fn($x, $y) => $x*$y
\$x => $x
\($x, $y) => $x*$y
$x ==> $x
($x, $y) ==> $x*$y
I think the main qualities of these possibilities are:
* Implementation complexity: fn and \ are easy, ==> is hard (lexer hack).
* Availability of reduced syntax: \ an ==> have a special single-argument
syntax, fn doesn't.
* Obviousness/readability: fn and ==> are obvious, while \ is not.
Especially \$x => $x looks quite obscure to the uninitiated (is that a
variable escape, like it would be in strings?)
At this point I'm considering to either a) move forward with fn() as the
choice I'd consider most likely to gather a consensus or b) have a
secondary three-way vote between these three syntax choices.
Nikita
Hi,
Even if a consensus wasn't reached I feel that there has been
quite a constructive discussion, where the pros and cons were
drilled down for the syntax alternatives at hand.
So having no voting rights myself, but alternative B for voting
looks ok in my eyes. One could ask having three alternatives
or two? OTOH, those three alternatives are now on the table
and nothing else, so all three. But if implementation of ==>
are much to overwhelming, only two.
r//Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
I cannot find my translations too. I've create German translations for these files: - ibase-add-user.xml - ibase-delete-user.xml - ibase-modify-user.xml Last time I was logged in I saw it still in pending state. I thought nobody was able to verify in German. But now the translations are gone completely. Maybe someone did a garbage collection ... Well, it wouldn't be a problem to translate again. But then the changes should also be incorporated. Regards, Martin -Ursprüngliche Nachricht- Von: Nikita Popov [mailto:nikita@gmail.com] Gesendet: Montag, 15. April 2019 12:28 An: Köditz, Martin Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase On Mon, Apr 15, 2019 at 12:17 PM Köditz, Martin wrote: > Hi Nikita, > > > To update the documentation you can either use the editor at > edit.php.net (useful for smaller changes and does not require > permissions), > > or also request direct commit access to the documentation. > I've added the changes via edit.php.net. But nothing happened since then. > I think it will be a good practice to request direct access. > > Thank you > Martin > I just tried to find your changes on edit.php.net, but didn't see anything related to interbase. Could you maybe provide a link to one of your patches? (Right click on the patch, then "View unified diff" and then click on "Direct link to this patch" at the top.) Regards, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
On Mon, Apr 15, 2019 at 12:17 PM Köditz, Martin wrote: > Hi Nikita, > > > To update the documentation you can either use the editor at > edit.php.net (useful for smaller changes and does not require > permissions), > > or also request direct commit access to the documentation. > I've added the changes via edit.php.net. But nothing happened since then. > I think it will be a good practice to request direct access. > > Thank you > Martin > I just tried to find your changes on edit.php.net, but didn't see anything related to interbase. Could you maybe provide a link to one of your patches? (Right click on the patch, then "View unified diff" and then click on "Direct link to this patch" at the top.) Regards, Nikita
[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hi Nikita, > To update the documentation you can either use the editor at edit.php.net > (useful for smaller changes and does not require permissions), > or also request direct commit access to the documentation. I've added the changes via edit.php.net. But nothing happened since then. I think it will be a good practice to request direct access. Thank you Martin -Ursprüngliche Nachricht- Von: Nikita Popov [mailto:nikita@gmail.com] Gesendet: Montag, 15. April 2019 12:08 An: Köditz, Martin Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase On Mon, Apr 15, 2019 at 11:51 AM Köditz, Martin wrote: > Hello everybody, > > I want to give you the general state of the Firebird driver. At the > end of January, I agreed to continue developing the Firebird driver as > a maintainer. In this regard, I first took care of getting familiar > with the code and an important bug (# 72175). > > Obviously, this information has not got through to the PHP community > for a variety of reasons. Unfortunately, the project seems to be > pulled away by the vote to remove the driver underfoot. > > It would be nice if someone could agree with me on the further steps > regarding further development. I particularly need help with the > following > points: > 1. How will I be deposited as a maintainer? > 2. Who has commit rights for changes? > 3. How are changes in the documentation checked in? Here are my > changes have not been committed for years. > 4. Where are the current development guidelines? I have an old book, > but it does not seem to reflect the current quality standards. > > Maybe it's to late. But maybe we (the Firebird and the PHP community) > can continue on a common path. > Hello Martin, The vote currently under way shouldn't change much for you: It mainly means that the code of the extension will be moved into a new repository and that the extension has to be installed using "pecl install interbase" instead of "./configure --with-interbase". Unless you already have one, please request a PHP git account at https://www.php.net/git-php.php. Once it is approved you will be granted access to the ext/interbase extension in php-src, as well as the new PECL repository for the extension once the move is completed. You can then commit changes using git via git.php.net. To update the documentation you can either use the editor at edit.php.net (useful for smaller changes and does not require permissions), or also request direct commit access to the documentation. Regards, Nikita
Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
On Mon, Apr 15, 2019 at 11:51 AM Köditz, Martin wrote: > Hello everybody, > > I want to give you the general state of the Firebird driver. At the end of > January, I agreed to continue developing the Firebird driver as a > maintainer. In this regard, I first took care of getting familiar with the > code and an important bug (# 72175). > > Obviously, this information has not got through to the PHP community for a > variety of reasons. Unfortunately, the project seems to be pulled away by > the vote to remove the driver underfoot. > > It would be nice if someone could agree with me on the further steps > regarding further development. I particularly need help with the following > points: > 1. How will I be deposited as a maintainer? > 2. Who has commit rights for changes? > 3. How are changes in the documentation checked in? Here are my changes > have not been committed for years. > 4. Where are the current development guidelines? I have an old book, but > it does not seem to reflect the current quality standards. > > Maybe it's to late. But maybe we (the Firebird and the PHP community) can > continue on a common path. > Hello Martin, The vote currently under way shouldn't change much for you: It mainly means that the code of the extension will be moved into a new repository and that the extension has to be installed using "pecl install interbase" instead of "./configure --with-interbase". Unless you already have one, please request a PHP git account at https://www.php.net/git-php.php. Once it is approved you will be granted access to the ext/interbase extension in php-src, as well as the new PECL repository for the extension once the move is completed. You can then commit changes using git via git.php.net. To update the documentation you can either use the editor at edit.php.net (useful for smaller changes and does not require permissions), or also request direct commit access to the documentation. Regards, Nikita
[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase
Hello everybody, I want to give you the general state of the Firebird driver. At the end of January, I agreed to continue developing the Firebird driver as a maintainer. In this regard, I first took care of getting familiar with the code and an important bug (# 72175). Obviously, this information has not got through to the PHP community for a variety of reasons. Unfortunately, the project seems to be pulled away by the vote to remove the driver underfoot. It would be nice if someone could agree with me on the further steps regarding further development. I particularly need help with the following points: 1. How will I be deposited as a maintainer? 2. Who has commit rights for changes? 3. How are changes in the documentation checked in? Here are my changes have not been committed for years. 4. Where are the current development guidelines? I have an old book, but it does not seem to reflect the current quality standards. Maybe it's to late. But maybe we (the Firebird and the PHP community) can continue on a common path. Regards, Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP deserialization techniques offer rich pickings for security researchers
Hi! > Thanks for responding to this issue. > > Will calling getMetaData still parse and > execute malicious code? If it's contained in phar and serialized data and the surrounding code (I understand that most techniques mentioned in the article rely on certain vulnerable code being present) then yes. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
