Re: [PHP-DEV] Argon2 default time cost
On Mon, Mar 25, 2019 at 10:18 PM Sara Golemon wrote: > ...snip... > So that's a long winded way of asking, does anyone see an issue with upping > the default time cost for argon2 to a higher number? (e.g. "3") > ...snip... > The only negative impact is that password hashing becomes a slightly more > expensive task. Where "slightly" means 3ms instead of 2ms on my Linux VM > running on my 2 core Mac laptop. > Thanks for tackling this work, Sara. As has been said, "whatever cost people choose should be reevaluated from time to time." [1] Now's as good a time as any. I have no objection. bishop [1]: https://www.usenix.org/legacy/publications/library/proceedings/usenix99/provos/provos_html/node6.html
[PHP-DEV] Argon2 default time cost
In sitting down to expose libsodium's argon2i password hashing function via
password_hash(), I discovered two things.
The first is that it doesn't seem to support Argon2id for password storage
the way we use it in password_hash(). Bummer, but that's a conversation to
have with Frank, and there's nothing we can do about it for the foreseeable
future.
The second is that crypto_pwhash_str() and crypto_pwhash_str_verify()
reject any attempt to use a "time_cost" value less than three. Wanna guess
what our default time_cost value is? That's right, it's two.
So that's a long winded way of asking, does anyone see an issue with upping
the default time cost for argon2 to a higher number? (e.g. "3") This will
ensure that the following actually works as expected and doesn't give users
confusing result and more importantly, allows us to use sodium to back
argon hashing interchangeably with the more lenient libargon.
$hash = password_hash("Foo", PASSWORD_ARGON2I);
var_dump(sodium_crypto_pwhash_str_verify($hash, "Foo")); // currently
FALSE, due to t < 3.
The only negative impact is that password hashing becomes a slightly more
expensive task. Where "slightly" means 3ms instead of 2ms on my Linux VM
running on my 2 core Mac laptop.
-Sara
Re: [PHP-DEV] [RFC] Unbundle ext/interbase
Hi! > I see the following options to go about this extension: > > 1) Add a deprecation warning as the functionality will effective cease > to exist in php-src. We don't know if this extension will be taken As an end user (in this case, PHP developer that needs to use Firebase functionality), I couldn't care less where the source code that compiles to the extension lives - php-src or pecl. So warning me about that is not very useful for me. If it gets moved to pecl, I'll discover it from UPGRADING note, amend my install list to fetch the pecl package and that should be the end of the matter for me. In my opinion, deprecation warnings should be used for functionality that the used needs to remove from the code. That's not what we're doing here - and that's not realistic for us to ask people to do, since it's not likely they'd just drop their DB backend. They'd use PECL package instead, or older version. The proper place to warn about this is the release notes (UPGRADING), not runtime deprecation warnings. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
Hi Stas Den tir. 26. mar. 2019 kl. 00.54 skrev Stanislav Malyshev : > That means both extensions are effectively unmaintained for over a > decade. If this does not happen, then continuing to ship it as part of > PHP core distribution is not doing the users any favors. Please see this RFC I recently posted regarding this subject (and the relevant internals thread): https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Firebird - Who are WE ...
Hi! > "we" are. Like are you kidding me, honestly. Can't you just say > whether it is "we" as in: > > - The Firebird community > - The Interbase community > - or a combination? > - Borland? > - Aston Tate? > - The dBase developers? Also, I wonder could someone from the "we" come forward and sign up as maintainer for any Firebird/Interbase code? Right now we have: EXTENSION: interbase PRIMARY MAINTAINER: Ard Biesheuvel (2003 - 2005) EXTENSION: pdo_firebird PRIMARY MAINTAINER: Lars Westermann (2007 - 2007) That means both extensions are effectively unmaintained for over a decade. If this does not happen, then continuing to ship it as part of PHP core distribution is not doing the users any favors. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
Hi, On Mon, Mar 25, 2019 at 8:02 PM G. P. B. wrote: > > On Mon, 25 Mar 2019 at 16:38, Andrey Andreev wrote: >> >> OK, so why not flip it and make it always available instead? I'm aware >> of the potential XML conflict, but I've personally never seen it, so >> to me that looks like the lesser evil compared to a massive BC break. >> >> Cheers, >> Andrey. > > > Technically this is already the case, the default in the engine is to enable > PHP's short open tags, however both INI config templates provided > with PHP (php.ini-developement and php.ini-production) disable PHP's short > open tags. > So if PHP's short open tags are to be considered "full class" open tags this > should be represented in the INI templates. But I won't be the > one pushing for this change. > We're talking about removal of the INI setting ... Aside of saying you wouldn't be personally pushing for what I suggested, I don't get the point of what you wrote. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
> On Mar 25, 2019, at 11:56, Peter Bowyer wrote: > > On Mon, 25 Mar 2019 at 15:24, Andreas Heigl wrote: > >> Shall we then also expect people that vote "yes" to explain why they voted >> for the feature? To see whether they understood what they where voting on? >> > > Yes. > > >> Then we should couple the vote to a comment in the wikinpage and without a >> comment there's no way to vote. >> >> That way all the information would be readily available in the RFC and no >> one would need to add comments after an RFC was voted upon. Because IMO >> that information as well as the process that lead to acceptance of the RFC >> are also important to afterwards make clear why that feature was >> implememted the way it was. So all RFCs and also all voters would be >> treated the same. >> > > Yes, that is the system I would like. Whether the comments are hidden > during voting or visible I have no strong feelings - but I would like a > comment to be required to vote. As you say it is useful history. > > People may enter nonsense into the comment field. They may paste in their > message(s) from internals. I'm OK with any of that as it's an experiment. > If it's not useful, we can stop asking for a comment. > > Given the concerns raised around voting, it would be interesting to see the > effect this has. If someone enters nonsense or “n/a” or any value that doesn’t justify their vote or doesn’t appear to satisfactorily justify it according to some metric of justification satisfaction, then does that person’s vote get thrown out or discounted? What is the goal of the experiment? Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
As long as it dosn't remove ' wrote: > > Hello, > > On Mon, 25 Mar 2019 at 14:02, G. P. B. wrote: > > > > Hello internals, > > > > I would like to start the discussion about the deprecation of PHP's short > > open tags: > > https://wiki.php.net/rfc/deprecate_php_short_tags > > > > As this is my first RFC all feedback is welcome. > > However, due to the nature of the RFC and it being self-contained, the > > planned date to > > beginning voting this RFC is after the mandatory two weeks discussion > > period and would > > start on Monday the 8th of April (2019-04-08) and be open for two weeks > > until Monday the > > 22nd of April (2019-04-22). > > > > Best regards > > > > George P. Banyard > > Short opening tags are by default disabled in the php.ini settings on > the majority of PHP installations. This means that writing modern PHP > code shouldn't use these anymore because the code isn't properly > portable or let's say it is less portable. On top of all removing > these would also simplify things a bit - one opening tag for the same > thing less. > > Also, a quick opinion based poll has been done in the PHP.earth > Facebook group [1] with ~96% in favour of the removal. > > So, +1 for removing these and simplify things more. There are only two > tags really needed in PHP templating engines > [1]: https://fb.com/groups/2204685680/permalink/10157687999015681/ > > Best regards. > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
Hello, On Mon, 25 Mar 2019 at 14:02, G. P. B. wrote: > > Hello internals, > > I would like to start the discussion about the deprecation of PHP's short > open tags: > https://wiki.php.net/rfc/deprecate_php_short_tags > > As this is my first RFC all feedback is welcome. > However, due to the nature of the RFC and it being self-contained, the > planned date to > beginning voting this RFC is after the mandatory two weeks discussion > period and would > start on Monday the 8th of April (2019-04-08) and be open for two weeks > until Monday the > 22nd of April (2019-04-22). > > Best regards > > George P. Banyard Short opening tags are by default disabled in the php.ini settings on the majority of PHP installations. This means that writing modern PHP code shouldn't use these anymore because the code isn't properly portable or let's say it is less portable. On top of all removing these would also simplify things a bit - one opening tag for the same thing less. Also, a quick opinion based poll has been done in the PHP.earth Facebook group [1] with ~96% in favour of the removal. So, +1 for removing these and simplify things more. There are only two tags really needed in PHP templating engines https://fb.com/groups/2204685680/permalink/10157687999015681/ Best regards. -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
Seems like the discussion is split between this thread and the previous one. This is maybe due to me not linking the RFC announcement email in the RFC immediately and I apologize for this inconvenience. I will try to answer to most things within the announcement thread. If I missed someone could they please notify me. On Mon, 25 Mar 2019 at 14:52, Reinis Rozitis wrote: > Hi, > I did read the initial thread about this and now the RFC and it doesn't > really state what is the reason of removing the short tags besides this one > line: > "PHP has provided over the years different ways to indicate the beginning > of PHP code other than the standard " > > Is there a (noticeable) speed improvement or does it make the > parser/engine more simple? Is it wrong to provide different ways to > indicate the start of php code? > Since the short ' You could argue that ' Also considering there is somewhat low adoption of new php versions [1] a > change which brakes a lot of legacy code might even further push back the > switch to modern/current versions (at least now even if the defaults > disable the short tags, there is an option to reenable the functionality). > Obviously you could say that those using old versions won't be affected > anyways and those using php 7.x and waiting for 8.x will use recent > application code and also won't notice this deprecation, but in my opinion > (and praxes) it isn't always the case. > > [1] https://w3techs.com/technologies/details/pl-php/all/all > > rr > Just as a reminder exposing PHP's version can be disabled with the "expose_php" INI setting. Maybe this is just me idealising stuff but as there is automatics tooling (as pointed out by Côme Chilliet) I would suppose that upgrading from PHP 7 to PHP 8 wouldn't be harder if PHP's short open tags get removed. On Mon, 25 Mar 2019 at 16:38, Andrey Andreev wrote: > OK, so why not flip it and make it always available instead? I'm aware > of the potential XML conflict, but I've personally never seen it, so > to me that looks like the lesser evil compared to a massive BC break. > > Cheers, > Andrey. Technically this is already the case, the default in the engine is to enable PHP's short open tags, however both INI config templates provided with PHP (php.ini-developement and php.ini-production) disable PHP's short open tags. So if PHP's short open tags are to be considered "full class" open tags this should be represented in the INI templates. But I won't be the one pushing for this change. On Mon, 25 Mar 2019 at 16:16, Johannes Schlüter wrote: > On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > > > As we stand now, code using short open tags works when those tags are > > enabled. As we'd stand in the future, that code would not work. > > That > > level of BC break requires a strong justification. > > The code would not simply "not work" but even potentially leak to the > client (as PHP would not treat it as code) which could leak credentials > or other sensitive information. > I think this can be an interesting point to add to the RFC as why to deprecate the short open tags. I still think that long-term goal should be that language behavior > doesn't depend on ini configuration. > > [...] > > johannes > This is mostly my reasonning on why bringing this RFC to the table. On Mon, 25 Mar 2019 at 17:21, Rasmus Schultz wrote: > For the record, we're a mid-size organization, building a modern product on > PHP 7 with a PSR-based stack. > > We've shunned template engines and rely heavily on short open tags and > alternative control-structures - mainly because we insist on static > analysis and IDE support, which we get by manually type-hinting a single > view-model variable $view at the beginning of each template. > > No other template engine gives us what we want in terms of static analysis, > type-checking or IDE support. > > The choice to rebuild a very large product in PHP vs e.g. Node, at the > time, was in part motivated by PHP's template features - which, while it > may look pretty verbose and ugly on the surface, has a huge advantage over > basically anything else, e.g. static analysis with various QA tools, > automated refactorings (rename etc.) in PHP Storm, and so on. > > The loss of this feature would be a substantial setback for our > organization - for which there is no really good replacement. This is an interesting use case, however may I ask why using '
Re: [PHP-DEV] Deprecate short_open_tag ini directive?
For the record, we're a mid-size organization, building a modern product on PHP 7 with a PSR-based stack. We've shunned template engines and rely heavily on short open tags and alternative control-structures - mainly because we insist on static analysis and IDE support, which we get by manually type-hinting a single view-model variable $view at the beginning of each template. No other template engine gives us what we want in terms of static analysis, type-checking or IDE support. The choice to rebuild a very large product in PHP vs e.g. Node, at the time, was in part motivated by PHP's template features - which, while it may look pretty verbose and ugly on the surface, has a huge advantage over basically anything else, e.g. static analysis with various QA tools, automated refactorings (rename etc.) in PHP Storm, and so on. The loss of this feature would be a substantial setback for our organization - for which there is no really good replacement. On Tue, Mar 12, 2019 at 10:51 AM Rowan Collins wrote: > On Mon, 11 Mar 2019 at 20:06, G. P. B. wrote: > > > From my understanding, the ` directive, > > so maybe we should deprecate PHP's short tag altogether? > > > > > I think when that's been proposed in the past, people have said they like > it for use in simple templates, often along with the "alternative control > structures", e.g.: > > > quantity > 1 ): ?>description; ?> endif; ?> > > > I couldn't find any discussions for a few years, though, so it's possible > opinions have changed. > > Regards, > -- > Rowan Collins > [IMSoP] >
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
Le lundi 25 mars 2019, 08:45:22 CET Thomas Hruska a écrit : > If this moves forward, I, and many others, will demand a formal, fully > supported utility for locating and automatically transforming all usages > of short open tags on the system. That is, a scanner to locate every > line of code that uses them with options to change the code > automatically. You can use the fixer "full_opening_tag" of php-cs-fixer: https://cs.symfony.com/ There is also "no_short_echo_tag" if you want to replace "http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate short_open_tag ini directive?
On 25/03/2019 16:38, Andrey Andreev wrote: > > OK, so why not flip it and make it always available instead? I'm aware > of the potential XML conflict, but I've personally never seen it, so > to me that looks like the lesser evil compared to a massive BC break. I slightly lean towards removing support for ' signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 15:24, Andreas Heigl wrote: > Shall we then also expect people that vote "yes" to explain why they voted > for the feature? To see whether they understood what they where voting on? > Yes. > Then we should couple the vote to a comment in the wikinpage and without a > comment there's no way to vote. > > That way all the information would be readily available in the RFC and no > one would need to add comments after an RFC was voted upon. Because IMO > that information as well as the process that lead to acceptance of the RFC > are also important to afterwards make clear why that feature was > implememted the way it was. So all RFCs and also all voters would be > treated the same. > Yes, that is the system I would like. Whether the comments are hidden during voting or visible I have no strong feelings - but I would like a comment to be required to vote. As you say it is useful history. People may enter nonsense into the comment field. They may paste in their message(s) from internals. I'm OK with any of that as it's an experiment. If it's not useful, we can stop asking for a comment. Given the concerns raised around voting, it would be interesting to see the effect this has. Peter
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
On 3/25/2019 6:02 AM, G. P. B. wrote: Hello internals, I would like to start the discussion about the deprecation of PHP's short open tags: https://wiki.php.net/rfc/deprecate_php_short_tags As this is my first RFC all feedback is welcome. However, due to the nature of the RFC and it being self-contained, the planned date to beginning voting this RFC is after the mandatory two weeks discussion period and would start on Monday the 8th of April (2019-04-08) and be open for two weeks until Monday the 22nd of April (2019-04-22). Best regards George P. Banyard If this moves forward, I, and many others, will demand a formal, fully supported utility for locating and automatically transforming all usages of short open tags on the system. That is, a scanner to locate every line of code that uses them with options to change the code automatically. (I don't know of anyone who is going to eagerly sift through a giant mess of grep output.) I manage hundreds of *internal* software applications that use short open tags. This proposal, as it stands, will *flood* log files with deprecation notices in 7.4 and risks exposure of/leaking information like database credentials and various secrets like XSRF token bases if someone simply updates to PHP 8 (e.g. upgrades the OS, which has a PHP 8 package). It would be incredibly short-sighted to deprecate and remove this but not offer tools to developers and deployers to find code that needs to be changed before doing the upgrade. This proposal contains at least one system security issue. OS package managers (apt, yum, etc.) will have to deploy either the aforementioned scanner/updater tool and/or look specifically at the relevant existing PHP INI setting during upgrade paths and possibly reject the system upgrade if it finds even one usage of short open tags on the system. When I write public, open source software, I always use 'of default INI settings (I'm pretty sure that setting is already Off by default in the production INI), but I prefer short open tags in certain environments. However, I'm not necessarily against this proposal. I just don't think all of the ramifications have been thought through. I also think the RFC needs to be updated to mention the various concerns I just mentioned under the RFC Impact section. On a side note, 'declared an always-on short open tag that doesn't interfere with 'security-related problems. That is, it is probably fairly rare to find '' since important secrets like that are generally shunted into a nicely formatted 'settings.php' file. However, code like ' would break but '' would not - the latter, IMO, being more readable anyway. This doesn't change the fact that I'd still want a utility to automatically locate upgrade issues. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bool values and increment operators?
Hi, On Mon, Mar 25, 2019 at 5:09 PM Chase Peeler wrote: > > 1.) Update the documentation to add booleans to the second list > 2.) Update the documentation to remove the second list - anything not in > the first list is not affected. > 3.) Update the language so that ++ and -- cast booleans to ints. > 4.) Emit warnings in those cases? I don't see a problem with how it currently works, but I do see a problem with it being silent. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate short_open_tag ini directive?
Hi, On Mon, Mar 25, 2019 at 5:16 PM Johannes Schlüter wrote: > > On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > > > As we stand now, code using short open tags works when those tags are > > enabled. As we'd stand in the future, that code would not work. > > That > > level of BC break requires a strong justification. > > The code would not simply "not work" but even potentially leak to the > client (as PHP would not treat it as code) which could leak credentials > or other sensitive information. > > I still think that long-term goal should be that language behavior > doesn't depend on ini configuration. > OK, so why not flip it and make it always available instead? I'm aware of the potential XML conflict, but I've personally never seen it, so to me that looks like the lesser evil compared to a massive BC break. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bool values and increment operators?
On Mon, 25 Mar 2019 at 15:03, Christian Schneider wrote: > The documentation has a highlighted box stating > "Note: The increment/decrement operators only affect numbers and strings. > Arrays, objects and resources are not affected. Decrementing NULL values > has no effect too, but incrementing them results in 1." > The NULL part of that has always baffled me. Why should ++ not be symmetrical with -- here? In general, documenting what we currently do is great, but is separate from agreeing that it's what we *should* do. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC Process: more productive conversations
> Am 25.03.2019 um 15:39 schrieb Peter Bowyer : > >> On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote: >> >> I don't believe forcing people to explain their votes actually does that. >> >> It does something quite similar, of forcing people to try to >> articulate how the RFC needs to change for them to change their vote >> from a no to a yes. At least that is how I have perceived the >> intentions of people who have asked for 'no' voters to explain their >> vote. >> > > It also ties in with the view previously expressed that we should restrict > voting rights because (my paraphrase) "too many people can vote for > something they don't understand and won't have to maintain". > > Asking people to say why they voted the way they did helps explore this: > can people give a cogent reason for their vote? Shall we then also expect people that vote "yes" to explain why they voted for the feature? To see whether they understood what they where voting on? Then we should couple the vote to a comment in the wikinpage and without a comment there's no way to vote. That way all the information would be readily available in the RFC and no one would need to add comments after an RFC was voted upon. Because IMO that information as well as the process that lead to acceptance of the RFC are also important to afterwards make clear why that feature was implememted the way it was. So all RFCs and also all voters would be treated the same. Just my 0.02€ Cheers Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate short_open_tag ini directive?
On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > As we stand now, code using short open tags works when those tags are > enabled. As we'd stand in the future, that code would not work. > That > level of BC break requires a strong justification. The code would not simply "not work" but even potentially leak to the client (as PHP would not treat it as code) which could leak credentials or other sensitive information. I still think that long-term goal should be that language behavior doesn't depend on ini configuration. Also creating a tool which does the conversion is relatively simple. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bool values and increment operators?
On Mon, Mar 25, 2019 at 11:03 AM Christian Schneider wrote: > Am 25.03.2019 um 15:43 schrieb Dan Ackroyd : > > So this code: > > > > > > >declare(strict_types=1); > > > >$i = true; > >$i++; > >var_dump($i); > >$i--; > >var_dump($i); > > > > > >$i = false; > >$i++; > >var_dump($i); > >$i--; > >var_dump($i); > > > > outputs: > > > >bool(true) > >bool(true) > >bool(false) > >bool(false) > > > > which is quite surprising on multiple levels. > > The documentation has a highlighted box stating > "Note: The increment/decrement operators only affect numbers and strings. > Arrays, objects and resources are not affected. Decrementing NULL values > has no effect too, but incrementing them results in 1." > > I guess bools should be added to the list of things not affected. > > $i = false; $i+=1; var_dump($i); that outputs int(1) I'd say that 1.) Update the documentation to add booleans to the second list 2.) Update the documentation to remove the second list - anything not in the first list is not affected. 3.) Update the language so that ++ and -- cast booleans to ints. I don't think #3 is actually a good solution. > - Chris > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] bool values and increment operators?
Am 25.03.2019 um 15:43 schrieb Dan Ackroyd : > So this code: > > >declare(strict_types=1); > >$i = true; >$i++; >var_dump($i); >$i--; >var_dump($i); > > >$i = false; >$i++; >var_dump($i); >$i--; >var_dump($i); > > outputs: > >bool(true) >bool(true) >bool(false) >bool(false) > > which is quite surprising on multiple levels. The documentation has a highlighted box stating "Note: The increment/decrement operators only affect numbers and strings. Arrays, objects and resources are not affected. Decrementing NULL values has no effect too, but incrementing them results in 1." I guess bools should be added to the list of things not affected. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bool values and increment operators?
Hi internals, So this code: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote: > I don't believe forcing people to explain their votes actually does that. > > It does something quite similar, of forcing people to try to > articulate how the RFC needs to change for them to change their vote > from a no to a yes. At least that is how I have perceived the > intentions of people who have asked for 'no' voters to explain their > vote. > It also ties in with the view previously expressed that we should restrict voting rights because (my paraphrase) "too many people can vote for something they don't understand and won't have to maintain". Asking people to say why they voted the way they did helps explore this: can people give a cogent reason for their vote? Peter
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote:
> On Mon, 25 Mar 2019 at 13:30, Rowan Collins
> wrote:
> >
> > One suggestion for an additional section: update the RFC with feedback,
> > particularly if it is withdrawn or rejected.
>
> I think that knowledge could live separately from the RFCs, which is
> why I'm maintaining https://github.com/Danack/RfcCodex
>
> The reasons for doing it separately are:
>
> * the last thing someone wants to do after having their RFC voted down
> is spending more time documenting it.
>
That feels pessimistic to me: is assumes that the author feels unhappy with
the RFC failing, rather than taking on board the feedback. You already have
a section headed "Don't be too put out if people don't like your RFC", and
I think taking on board why people disagreed is a big part of that.
> * some ideas have had multiple RFCs, while other ideas are proposed on
> the list without having a formal RFC. For both scenarios documenting
> why it failed in a single place needs to be elsewhere than an RFC
> page.
>
That's certainly an issue, which I've suggested before in the form of an
"Internals FAQ". However, it somewhat contradicts your previous point:
you're now asking someone to do *even more work* after an RFC is rejected,
to summarise it in a new format, in a new location. Either that's the RFC
author, or it's someone interested enough that they could offer to write it
in the RFC itself.
As RFCs re-raising previous ideas, they can and should link to and explain
their relationship to related RFCs, and this should probably be in the
guidelines if it's not already.
> > It has actually been suggested multiple times that
> > voters *should* justify their votes,
>
> Yes. However that is unlikely to provide a useful conversation.
> Thinking that the RFC is just a terrible idea is always a valid reason
> to vote no. Having people say that "this RFC is terrible" doesn't lead
> to a productive conversation.
>
That's because it's an unhelpful comment. What does "terrible" mean? Other
than "I assume you raised this in bad faith", there is *always* a more
productive explanation than that - "I don't think this fits the
style/purpose/scope of the language", "I think this would encourage/only be
useful for bad practices", etc.
> > so that it's clear whether a future RFC could address the
> > perceived problems,
>
> I don't believe forcing people to explain their votes actually does that.
>
Right, which is why I said I'm on the fence about *forcing* it, but that we
should at least *encourage* it.
> The problem with that is that some RFCs are just fundamentally not
> good and so there isn't any changes that could be made that would make
> the RFC acceptable.
>
> In those scenarios, putting pressure on 'no' voters to say what needs
> to be fixed, is just putting pressure on people to not vote no.
>
I don't think that follows. If the answer to "what would make you change
your mind?" is "nothing", that's still useful feedback - it tells future
RFC authors not to approach the suggestion at all.
> Additionally in some of the RFC discussions we've had, where the
> author has asked for people to explain the 'no' votes, the reasons
> have already been said clearly in the discussion phase.
>
Yes, the important thing is that the different reasons for no votes are
captured, not that the exact counts for each are tallied. It's also a
reason to add a text field to the voting widget: it doesn't invite
responses in the same way a post to the mailing list thread does.
I think a reasonable compromise is to say that voters should mention the
reasons they're voting no if they have not already been mentioned; but that
proposers should assume that votes without a reason are agreeing with
previously stated reasons. That discourages voters assuming proposers can
read their mind ("well, obviously it's bad") but also discourages proposer
pestering and cross-examining voters.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Deprecate short_open_tag ini directive?
On Tue, Mar 12, 2019 at 11:57 AM Stanislav Malyshev wrote: > > I'm currently going through the PHP doc to remove mentions of PHP 4 > > and stumbled upon the short_open_tag ini directive [1] which only affects > > the availability of ` > From my understanding, the ` > so maybe we should deprecate PHP's short tag altogether? > > Why? What would it improve for people that are using it? For people that > aren't, it obviously won't change anything. So what would be the > motivation for this change? > I'm with Stas (and some others in disconnected sub-threads because email is hard). This RFC needs a better "why this is important" section. Yeah, I get that it being an option makes writing portable code harder, I get that the XML open tag is something that can be tripped on, but why is removing it a sufficiently better solution to the "problem"? As we stand now, code using short open tags works when those tags are enabled. As we'd stand in the future, that code would not work. That level of BC break requires a strong justification. -Sara
Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags
On Mon, Mar 25, 2019 at 9:52 AM Reinis Rozitis wrote: > > I would like to start the discussion about the deprecation of PHP's > short open > > tags: > > https://wiki.php.net/rfc/deprecate_php_short_tags > > Hi, > I did read the initial thread about this and now the RFC and it doesn't > really state what is the reason of removing the short tags besides this one > line: > "PHP has provided over the years different ways to indicate the beginning > of PHP code other than the standard " > > Is there a (noticeable) speed improvement or does it make the > parser/engine more simple? Is it wrong to provide different ways to > indicate the start of php code? > Since the short ' > I'm still unclear on the advantages as well > Also considering there is somewhat low adoption of new php versions [1] a > change which brakes a lot of legacy code might even further push back the > switch to modern/current versions (at least now even if the defaults > disable the short tags, there is an option to reenable the functionality). > Obviously you could say that those using old versions won't be affected > anyways and those using php 7.x and waiting for 8.x will use recent > application code and also won't notice this deprecation, but in my opinion > (and praxes) it isn't always the case. > > Our application (an internal webapp) has a large amount of legacy code that we try to avoid messing with because we are actively rebuilding everything. Everytime there is a BC break we have to go back into that legacy code. So, while any active development of our application uses "recent application code" that is that difficult to maintain, we still have a lot of spaghetti code that we rarely have to deal with except when it comes time to upgrade PHP. This often leads to the upgrades getting pushed out further and further. I'm not against BC breaks. They are a necessary evil to make PHP a better language. However, I think there should be a clear reason why the advantages outweigh the disadvantages. I'm not seeing that in this case. > [1] https://w3techs.com/technologies/details/pl-php/all/all > > rr > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 13:30, Rowan Collins wrote: > > One suggestion for an additional section: update the RFC with feedback, > particularly if it is withdrawn or rejected. I think that knowledge could live separately from the RFCs, which is why I'm maintaining https://github.com/Danack/RfcCodex The reasons for doing it separately are: * the last thing someone wants to do after having their RFC voted down is spending more time documenting it. * some ideas have had multiple RFCs, while other ideas are proposed on the list without having a formal RFC. For both scenarios documenting why it failed in a single place needs to be elsewhere than an RFC page. > It has actually been suggested multiple times that > voters *should* justify their votes, Yes. However that is unlikely to provide a useful conversation. Thinking that the RFC is just a terrible idea is always a valid reason to vote no. Having people say that "this RFC is terrible" doesn't lead to a productive conversation. > so that it's clear whether a future RFC could address the > perceived problems, I don't believe forcing people to explain their votes actually does that. It does something quite similar, of forcing people to try to articulate how the RFC needs to change for them to change their vote from a no to a yes. At least that is how I have perceived the intentions of people who have asked for 'no' voters to explain their vote. The problem with that is that some RFCs are just fundamentally not good and so there isn't any changes that could be made that would make the RFC acceptable. In those scenarios, putting pressure on 'no' voters to say what needs to be fixed, is just putting pressure on people to not vote no. Additionally in some of the RFC discussions we've had, where the author has asked for people to explain the 'no' votes, the reasons have already been said clearly in the discussion phase. But the RFC author has dismissed those reasons as 'invalid'. Again, trying to force people to justify their reasons, to the satisfaction of the RFC author isn't going to lead to a productive conversation. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Deprecate PHP's short open tags
> I would like to start the discussion about the deprecation of PHP's short open > tags: > https://wiki.php.net/rfc/deprecate_php_short_tags Hi, I did read the initial thread about this and now the RFC and it doesn't really state what is the reason of removing the short tags besides this one line: "PHP has provided over the years different ways to indicate the beginning of PHP code other than the standard " Is there a (noticeable) speed improvement or does it make the parser/engine more simple? Is it wrong to provide different ways to indicate the start of php code? Since the short 'https://w3techs.com/technologies/details/pl-php/all/all rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
Den man. 25. mar. 2019 kl. 15.30 skrev Rowan Collins : > > It isn't the responsibility of voters to explain why they're voting no. > > It has actually been suggested multiple times that voters *should* justify > their votes, so that it's clear whether a future RFC could address the > perceived problems, or if similar RFCs are likely to receive the same votes > against. I'm on the fence whether making it a hard requirement is > reasonable, but I don't think we should enshrine the opposite. As a voter and maintainer, I don't really wish to state my opinion on every single vote I do, I think that is too much. I know it is preferable as a maintainer, certainly, however instead I think to be following the proposed style of etiquette, it would be recommended, but not a hard requirement to state your reasoning for a vote. If anything I think we should extend the voting addon for dokuwiki to have such an option for primary voting polls. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 13:04, Dan Ackroyd wrote: > I've written some suggestions on people could have more productive > conversations which I'm going to maintain here > (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and > have attached to the end of this email. > Hi Dan, Thanks for putting this together, I think it's a great addition to the current RFC guidance. The only part I can see being controversial is this: > It isn't the responsibility of voters to explain why they're voting no. It has actually been suggested multiple times that voters *should* justify their votes, so that it's clear whether a future RFC could address the perceived problems, or if similar RFCs are likely to receive the same votes against. I'm on the fence whether making it a hard requirement is reasonable, but I don't think we should enshrine the opposite. One suggestion for an additional section: update the RFC with feedback, particularly if it is withdrawn or rejected. If someone comes along with a suggestion that's been discussed before, it's really helpful if we can say "see this page for why it didn't happen last time, and see if you can fix those issues", rather than just "it didn't get very far before, but we can't remember why". This is something I intend to do with my own "locked classes" RFC: I'm probably going to withdraw it because I don't have time to rework it, but will try to summarise where a new RFC could pick things up. Regards, -- Rowan Collins [IMSoP]
[PHP-DEV] RFC Process: more productive conversations
Hi Internals, A little while ago Zeev suggested that it was time to update the RFC process to make it more fit for purpose. As part of that conversation I would like to suggest some 'etiquette' around RFC discussions. PHP internals has a reputation for being 'toxic'. While I don't think it's as bad as some people try to suggest it is, we could make RFC discussions be more productive and less emotionally draining by people being more careful how they interact with each other on this list. I've written some suggestions on people could have more productive conversations which I'm going to maintain here (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and have attached to the end of this email. These would be mostly suggestions for keeping conversations rather than hard rules, as most of them involve gray areas, which couldn't and shouldn't be enforced with hard rules. I'm sending this list now, but the full conversation might be better to have as a part of a full review of the RFC process. However, there are a few that I think we should discuss sooner rather than later. # Better process for handling suggestions that are never likely to pass Recently, someone suggested adding the capability for PHP to print strings that are automatically terminated with a new line. Putting it mildly, that conversation didn't go well, as by the end of it people were swearing at each other on the list. PHP internals could do with a better process for giving negative feedback an idea without someone having to go through the whole RFC process. I don't have a good suggestion for how to do this. Does anyone else? # People other than the author announcing RFCs on internals Through possibly a series of errors, someone who was not the author started a thread on internals for an RFC right after it had been created, while it was still in draft status. The site wiki.php.net/rfc is a tool that is meant to allow people to draft RFCs and share the idea with other people who want to work on the RFC before it is a polished idea, and before it is ready to be presented to the world. Having someone other than the RFC author announce the RFC on internals before the author thinks the RFC is ready for comment, is "not okay". If you discuss an RFC on internals before the author thinks the RFC is ready to be discussed, the only thing that could achieve is to make the conversation less productive. If you want to influence how the RFC is drafted, it can appropriate to reach out to the RFC author, and offer to help them. # Contacting RFC authors should go through PHP internals list Drafting RFCs and pushing them through internals is an exhausting process. Several PHP contributors have suddenly stopped contributing to the project after successfully getting an RFC passed, due to them being entirely fed up. One of the things that quickly becomes tiresome is people contacting the RFC author (or voters) through communication channels (other than the PHP internals list), particularly when what they are going to say is either negative or even just based on not understanding part of the RFC. There is a difference between giving positive feedback and negative feedback. And there is a difference between giving feedback to someone you have communicated with many times before, and contacting someone for the first time. It's hard to draw an exact line for which communication is fine to go off-list, and which should stay on list. But here are some examples: "You are awesome for writing such an amazing RFC" - fine to send off-list. "I found some typos in the RFC" - probably fine to send off-list, particularly if you communicate with the RFC author already. "Please can you answer this question about the RFC" - possibly fine to send off-list, but only if you know the RFC author already. "The RFC is a terrible idea for these reasons" - should only be sent via the list. cheers Dan Below is the full list of suggestions. As I said, I'll maintain it at https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md until a more formal RFC process discussion kicks off. ## Don't publicise draft work The site wiki.php.net/rfc is a tool that is meant to allow people to draft RFCs and share the idea with other people who want to work on the RFC before it is a polished idea, and before it is ready to be presented to the world. Having someone other than the RFC author announce the RFC on internals before the author thinks the RFC is ready for comment, is "not okay". If you discuss an RFC on internals before the author thinks the RFC is ready to be discussed, the only thing that could achieve is to make the conversation less productive. If you want to influence how the RFC is drafted, it is appropriate to reach out to the RFC author, and offer to help them. ## Do open new RFCs rather than re-use existing documents. When revisiting ideas, and the previous version of an RFC hasn't been discussed in a long time (e.g. more than 6 months)
[PHP-DEV] [RFC] Deprecate PHP's short open tags
Hello internals, I would like to start the discussion about the deprecation of PHP's short open tags: https://wiki.php.net/rfc/deprecate_php_short_tags As this is my first RFC all feedback is welcome. However, due to the nature of the RFC and it being self-contained, the planned date to beginning voting this RFC is after the mandatory two weeks discussion period and would start on Monday the 8th of April (2019-04-08) and be open for two weeks until Monday the 22nd of April (2019-04-22). Best regards George P. Banyard
