On Mon, Jul 15, 2024, at 2:05 PM, Larry Garfield wrote:
> Hi all. I have just opened the voting on the property hook
> (performance) improvement RFC.
>
> https://wiki.php.net/rfc/hook_improvements
>
> With the readonly bits pushed out to later, this is probably the
> shortest RFC I have ever wri
> On Jul 30, 2024, at 4:26 PM, Tim Düsterhus wrote:
> The problem with adding standalone functions for every algorithm is that it
> would result in a combinatorial explosion of available functions.
I commented on this but as it was probably missed in a longer reply so I will
repeat.
There is n
On 30.07.2024 at 21:20, Tim Düsterhus wrote:
> What prevented me personally from adding a "soft deprecation" to the
> documentation is, that the function is not actually deprecated and not
> slated for deprecation. It is not up to me to decide to soft deprecate
> something.
Well, yeah, that needs
Hi
On 7/28/24 08:42, Rowan Tommins [IMSoP] wrote:
Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions for
both, and then when SHA4 comes along (as it inevitably will) another standalone
function for one of its variants?
You tell me. As I have repeatedly said, I don't act
Hi
On 7/28/24 00:25, Rob Landers wrote:
I'd love to see a "hashing" namespace and all of these given their own functions with
docblocks and manual pages instead of the current generic "god of hash" page which
doesn't even list the hash functions available; you have to click on hash_algos and t
Hi
On 7/28/24 14:24, Kamil Tekiela wrote:
I have voted yes only because I thought it's about removing inconsistent
function alias. I can't see anything wrong with this hashing algorithms and
I don't consider them unsafe. However, as someone pointed out this doesn't
seem to be correct as the crc3
Hi
On 7/28/24 06:33, Mike Schinkel wrote:
P.S. Frankly, I really would not want to see md5() nor sha1() removed because
there are valid use-cases for them. I would at least like to see them kept in
some form, maybe in an `\Insecure` namespace, or renamed `insecure_md5()` and
`insecure_sha1()`
Hi
On 7/27/24 13:24, Christoph M. Becker wrote:
Hmm, such soft deprecations should be a good thing, but I'm afraid they
are not really reaching much of the user base. Remember ext/mysql?
That was soft deprecated for "centuries", but still support channels
were burning when it actually had been
Hi
On 7/26/24 19:33, Rowan Tommins [IMSoP] wrote:
On Fri, 26 Jul 2024, at 15:20, Larry Garfield wrote:
One thing to remind people about, the deprecations for md5(), sha1(),
and uniqid() explicitly say they cannot be outright removed before PHP
10. That's at least 6 years away. That gives a lo
Hi
On 7/27/24 02:18, Juliette Reinders Folmer wrote:
Considering that the hash() function was introduced in PHP 5.1.2
(January 2006) and password_*() in PHP 5.5 (June 2013), I don't share
your optimism about tutorials being updated within six years
I attribute that to the fact that there
Hi
On 7/26/24 15:13, Rowan Tommins [IMSoP] wrote:
On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote:
I think you are expecting a little too much from a beginner that is
following "the modern PHP tutorial" if you expect them to critically
question whether the tutorial is actually good or not. T
On 30.07.2024 at 14:30, Gina P. Banyard wrote:
> On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker
> wrote:
>
>> Would that RFC imply that I would need to write `\\exit` or have a `use
>> exit` clause to avoid dynamic namespace lookup? If so, I would be even
>> less in favor of that change
On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker
wrote:
> Hi Gina!
>
> On 30.07.2024 at 11:49, Gina P. Banyard wrote:
>
> > I have just opened the vote for the "Transform exit() from a language
> > construct into a standard function" RFC:
> > https://wiki.php.net/rfc/exit-as-function
>
Hi Gina!
On 30.07.2024 at 11:49, Gina P. Banyard wrote:
> I have just opened the vote for the "Transform exit() from a language
> construct into a standard function" RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> The vote will last for two weeks until the 13th of August 2024.
As userland
On 29.07.2024 at 13:09, Ayesh Karunaratne wrote:
> Thank you for weighing in on this. There is PR 5094[^1] from you that
> proposed to deprecate several `CURLE_` constants. If we were to no-op
> this constant, I'd like to propose a deprecation RFC with all those
> changes combined.
>
> [^1]: https
15 matches
Mail list logo
