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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
>
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
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
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
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
> 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
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
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;
> >
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)
>
Hi internals,
So this code:
http://www.php.net/unsub.php
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
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
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
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
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
> 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
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
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,
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
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
33 matches
Mail list logo
