Hi Dmitry,
It doesn't make sense to wait another year for this, and since it's self
contained it's fine to merge into 8.1 when ready.
Cheers
Joe
On Wednesday, 7 July 2021, G. P. B. wrote:
> On Wed, 7 Jul 2021 at 10:31, Dmitry Stogov wrote:
>
> > Hi,
> >
> > Last week, at a PHP conference, we
Replying to Rowan and commenting on Nikita's message.
> On Jul 6, 2021, at 4:24 AM, Rowan Tommins wrote:
>
>> Instead I replied because your email strongly implied (stated?) that
>> "deprecation required removal"
>
> I stand by that interpretation, which while not universal is very widely
>
On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
> Hi internals
>
> With the readonly properties RFC almost certainly accepted, I'd like to
> discuss an idea that's slightly related to them.
>
> One of the problems that readonly properties solve is that they reduce
> the overhead of writing
On Jul 6, 2021, at 08:34, Daniel Beardsley wrote:
> The proposal:
>> Add a function that exposes the warning count of the most recent
>> statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int
>> straight from the MySQL driver. This fixes the open bug at:
>>
On Wed, Jul 7, 2021 at 2:40 PM Ralph Schindler wrote:
>
>
>
> >
> > It would theoretically be:
> >
> > $fn = MyController::myAction(...);
> >
> > It currently errors:
> >
> >> Fatal error: Uncaught Error: Non-static method MyController::myAction()
> >> cannot be called statically
> >
> > I
On Wed, Jul 7, 2021 at 10:41 PM Ralph Schindler
wrote:
>
>
> >
> > It would theoretically be:
> >
> > $fn = MyController::myAction(...);
> >
> > It currently errors:
> >
> >> Fatal error: Uncaught Error: Non-static method MyController::myAction()
> cannot be called statically
> >
> > I
It would theoretically be:
$fn = MyController::myAction(...);
It currently errors:
Fatal error: Uncaught Error: Non-static method MyController::myAction() cannot
be called statically
I would be okay with allowing this, as long as it's bound before it's called.
Could we do this
On Wed, 7 Jul 2021 at 10:31, Dmitry Stogov wrote:
> Hi,
>
> Last week, at a PHP conference, we discussed some missing parts of ext/ffi
> with one of the most extrimal FFI user - Alexandr Lisachenko. One of the
> things he is missing is a FFI Type Reflection API. Actually, this is a
> simple and
Hi internals
With the readonly properties RFC almost certainly accepted, I'd like to discuss
an idea that's slightly related to them.
One of the problems that readonly properties solve is that they reduce the
overhead of writing getters and setters. This is especially noticeable in
objects
On Tue, 6 Jul 2021 at 15:58, Michael Maroszek wrote:
>
> Dear internals,
>
> I didn't receive any more feedback on this RFC, therefore I would like to
> start voting next week on the RFC as is.
fyi, I think you'll need to update the 'Proposed PHP Version' to 8.2.
Ben Ramsey wrote on 22 Jun 2021
On Tue, Jul 6, 2021, at 6:54 PM, Bob Weinand wrote:
> Hey Larry,
>
> there's still ongoing discussion on the semantics, and mirroring
> implementation defined semantics from the implementation into the RFC
> is not the way to go. The RFC should discuss reasons of why semantics
> were chosen
Hey y'all,
I'm closing the vote for making `Reflection*#setAccessible()` no-op.
The result is a unanimous 31 votes **for** the change to be included in PHP
8.1: I will clean up https://github.com/php/php-src/pull/5412 and get it
ready for merge :-)
@Tyson sorry, I really forgot to update the
Sorry, let me check one thing.
The macros provided by ext/standard/php_random.h are currently being used
from several places. Merging this into ext/stanrard/php_rand.h would
require support for all dependent code.
Also, if a third party extension includes ext/standard/php_random.h and
uses the
OK. Continue working.
> Generally, you also need to initialize these is_null variables to true,
because if the parameter is not passed, then the variables will be left at
the default value and you want to treat "not passed" the same way as "null
was passed".
Oh, I didn't know that. Thank you
We'll do it that way.
Thanks for fixing the memory issue. I'm not quite sure I understand the
principle, so I will investigate.
By the way, are you working on something now? If so, I'll pause the work.
Regards,
Go Kudo
2021年7月7日(水) 21:41 Nikita Popov :
> On Wed, Jul 7, 2021 at 2:33 PM Go Kudo
Le 07/07/2021 à 14:32, Brent Roose a écrit :
Hi internals
With the readonly properties RFC almost certainly accepted, I'd like to discuss
an idea that's slightly related to them.
One of the problems that readonly properties solve is that they reduce the
overhead of writing getters and
On Wed, Jul 7, 2021 at 2:33 PM Go Kudo wrote:
> Incidentally, what would be the preferred name for the ext/standard random?
> I was going to rename it to random_func, but I have a feeling that would
> be controversial.
>
> - random_func.c / php_random_func.h / RANDOM_FUNC_G /
>
Incidentally, what would be the preferred name for the ext/standard random?
I was going to rename it to random_func, but I have a feeling that would be
controversial.
- random_func.c / php_random_func.h / RANDOM_FUNC_G /
php_random_func_bytes() / php_random_func_int()
- std_random.c ...
-
> We can rename the ext/standard header.
OK. I'll rename random in ext/standard. This will not be BC break maybe.
2021年7月7日(水) 19:32 Nikita Popov :
> On Tue, Jul 6, 2021 at 4:38 PM Go Kudo wrote:
>
>> > 1st
>>
>> This is to avoid conflicts with the implementation in ext/standard. I
>> don't
>>
On Tue, Jun 22, 2021 at 3:31 AM Ben Ramsey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi, all!
>
> This is a reminder from your friendly neighborhood 8.1 release managers
> letting you know that we’ll release the first beta for PHP 8.1 in 30
> days on 22 July.
>
> This means
On Tue, Jul 6, 2021 at 4:38 PM Go Kudo wrote:
> > 1st
>
> This is to avoid conflicts with the implementation in ext/standard. I don't
> want to do it this way either, but I have to do it this way.
> Since random in ext/standard does not use namespaces, I would like to
> change the ext/standard
On Tue, Jul 6, 2021 at 4:54 PM Go Kudo wrote:
> > Could you share some example of where you use it?
>
> It looks like mt_rand() could be replaced by mt_rand(0, getrandmax()), but
> that is not the case, mt_rand() with a specified range is an implementation
> that generates random numbers until
The perf numbers are for current implementation.
Predictability seems more important than simplicity, considering what the
feature is for.
The only way to make the simpler implementation predictable in the same
kind of way was found to be unacceptable during discussion.
Cheers
Joe
On
On Wed, 7 Jul 2021 at 10:23 am, Nikita Popov wrote:
> The RFC indicates that the impact is minor, but I believe those
> measurements were made with the original version of the RFC, which did not
> try to distinguish literal and non-literal interned strings
Hi Nikita,
The performance test
On Mon, Jul 5, 2021 at 8:15 PM Craig Francis
wrote:
> Hi Internals,
>
> I have opened voting on https://wiki.php.net/rfc/is_literal for the
> is-literal function.
>
> The vote closes 2021-07-19
>
> The proposal is to add the function is_literal(), a simple way to identify
> if a string was
Hi,
Last week, at a PHP conference, we discussed some missing parts of ext/ffi
with one of the most extrimal FFI user - Alexandr Lisachenko. One of the
things he is missing is a FFI Type Reflection API. Actually, this is a
simple and self-contained feature, that implementation took me a couple of
26 matches
Mail list logo
