Putting this to the "would this shorthand have passed if it were introduced by
a separate RFC on top of the base implementation" test, I think the answer
would have been a clear "no".
Regards,
Nikita
an implementation oversight, this is not actually true. I
consider the fact that extending anonymous classes is possible to be a bug,
which is why I also accept the minor backwards compatibility break that comes
with fixing it. Of course, the line between a bug and a feature is quite fine
sometimes, so I understand that people have differing views on where this falls.
Regards,
Nikita
On Sun, Dec 3, 2023, at 16:05, Nicolas Grekas wrote:
> Hello Nikita,
>
>> > I've just opened voting for the final anonymous classes RFC @
>> > https://wiki.php.net/rfc/final_anonymous_classes.
>> >
>> > Voting started now, and will run until Decem
could, in theory, have been used to extend anonymous classes in the past.
Especially given that there is no evidence of this "feature" being used in the
wild (or if there is such evidence, it was not presented in the proposal).
Regards,
Nikita
know that's not super accurate since
> a typed property is always defined semantically, but that's nonetheless the
> flag that is used in the source. Maybe this could help with the RFC.
This. The lazy initialization use case is the only reason why we still allow
declared properties to be unset at all.
Our long term plan was to find an alternative way to support lazy
initialization for properties, and then forbid calling unset() on declared
properties. However, we still don't have that alternative today.
Regards,
Nikita
nterested in.
So basically you have the choice between calling end(), which is the wrong
thing to do semantically and may be slow, or using
$array[array_key_last($array)], which is rather convoluted, and incorrect if
the array is potentially empty.
Regards,
Nikita
actual meaning of the parameters does
not change. Equivalent to a func_num_args() check in userland code. I think
these arity overloads are pretty harmless. The function signature is meaningful
and compatible with named arguments.
My overall inclination here is to vote No on all the deprecations that involve
arity overloads and vote Yes on the remainder.
Possibly I'm missing some kind of complication that the arity overloads are
causing?
Regards,
Nikita
On Sat, Jun 24, 2023, at 21:39, Nikita Popov wrote:
> On Fri, Dec 30, 2022, at 22:39, Christoph M. Becker wrote:
> > On 30.12.2022 at 22:12, Nikita Popov wrote:
> >
> > > On Thu, Nov 10, 2022, at 14:29, Christoph M. Becker wrote:
> > >
> > >&g
On Fri, Dec 30, 2022, at 22:39, Christoph M. Becker wrote:
> On 30.12.2022 at 22:12, Nikita Popov wrote:
>
> > On Thu, Nov 10, 2022, at 14:29, Christoph M. Becker wrote:
> >
> >> On 09.11.2022 at 23:27, Nikita Popov wrote:
> >>
> >>> It look
longest time, we only had mt_rand(), and no easy access to a CRPRNG. A
lot of mt_rand() misuse dates back to that time. Since the introduction of
random_int() and random_string(), getting cryptographic randomness is no harder
than getting non-cryptographic randomness (easier, in the case of strings).
Regards,
Nikita
is missing an important voting option, which is "leave them alone", or
rather "convert to some non-seedable non-CSPRNG" if you prefer.
Regards,
Nikita
e
defines to determine what a type code means. If you get type 18, good luck
figuring out what that means now.
>
> > https://github.com/php/php-src/commit/371ae12d890f1887f79b7e2a32f808b4595e5f60
>
> As you see in the commit message, this implements an (unwritten) rule
>
On Sun, Feb 19, 2023, at 09:21, Max Kellermann wrote:
> On 2023/02/19 08:56, Nikita Popov wrote:
> > If you have a function like zend_stream_open_function(), SUCCESS and
> > FAILURE are directly meaningful values.
>
> Agree, but that doesn't explain why FAILURE needs
return values indicate failure. This means that false
indicates success and true indicates failure. (I'm not kidding you -- I'm
literally working on a project that uses boolean return values with this
convention right now.)
The current guideline for use of bool and zend_result in php-src is that bool
is an appropriate return value for "is" or "has" style functions, which return
a yes/no answer. zend_result is an appropriate return value for functions that
perform some operation that may succeed or fail.
I think that's a pretty reasonable state of things, and don't think there is a
need to change it.
Regards,
Nikita
On Thu, Nov 10, 2022, at 14:29, Christoph M. Becker wrote:
> On 09.11.2022 at 23:27, Nikita Popov wrote:
>
> > It looks like GitHub has just added support for private security reports:
> > https://github.blog/changelog/2022-11-09-privately-report-vulnerabilities-to-repo
rity bug reports.
This would allow retiring the last remaining use of bugs.php.net (well,
apart from the archive of old issues, which should of course remain).
Regards,
Nikita
language.
> Order of execution
See
https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-and-memory-safety
for why the order of execution is the way it is. As class constants do not
support writes, these concerns do not apply, and the "normal" order can be
used (as you propose).
Regards,
Nikita
e plenty of cases where you just need to
> check if a string is a valid json and that is it. Just looking into
> stackoverflow will give you an idea about how many people is looking for
> something like this in an efficient way.
>
Could you please give some specific examples where the proposed
functionality would be useful?
Regards,
Nikita
es an arbitrary limitation and inconsistency, and removes
the need for people to work around this in ways that are much worse -- for
example, by having an implicit contract between the trait and the using
class, as shown in the RFC.
Regards,
Nikita
://externals.io/message/112709) to move to the successor,
> travis-ci.com, but I don't think we ever moved there.
>
> Quoting Nikita from that thread:
>
> > We haven't been using Travis as our primary CI for a while already. We
> use
> > AppVeyor for Windows
On Thu, Jun 9, 2022 at 9:39 PM Marco Pivetta wrote:
> Hey Nikita,
>
> On Thu, 9 Jun 2022 at 21:35, Nikita Popov wrote:
>
>> On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta wrote:
>>
>>>
>>> On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
>>>
On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta wrote:
>
> On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
>
>> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
>> wrote:
>>
>>> Hi,
>>>
>>> On jeudi 9 juin 2022 18:46:53 CEST Marco Pivetta wro
Foo::bar()" and Foo happens to be a parent of your current scope and bar()
a non-static method, then this performs a scoped instance call that
inherits $this. Not binding $this here would result in an Error exception,
but the compiler doesn't have any way to know that $this needs to be bound.
Regards,
Nikita
rt for fetching properties in constant
> expressions using the -> operator. I'm looking forward to your
> feedback.
>
> Regards,
> Ilija
>
This looks like a reasonable addition.
Could there be any expectation that if -> works, ?-> does as well?
Regards,
Nikita
Incidentally these get mapped to F_RDLCK,
F_WRLCK and F_UNLCK internally, which just so happen to have the same
values as LOCK_SH, LOCK_EX and LOCK_UN in PHP ;)
Is there some kind of evidence that people are actually trying to use these
as bitflags, and you're trying to solve a real problem here? Or is the only
problem being solved that somebody is celebrating their own ignorance and
incompetence over at r/lolphp again?
Regards,
Nikita
t.stackoverflow.com/rooms/11/php
>
> cheers,
> Derick
>
Keeping in mind that people deploying PHP on Linux usually end up using
OS-provided zoneinfo, do you know which source distros base that on? I
think we should follow the distro-consensus here, whatever that may be.
Regards,
Nikita
't think your scheme could extend to
those cases.
I'm not really convinced that it's worthwhile to invest effort in this
directly.
Regards,
Nikita
On Sun, Jan 30, 2022 at 5:41 PM Christian Schneider
wrote:
> Am 30.01.2022 um 16:55 schrieb Nikita Popov :
> > Something I want to add here is that there is also an important technical
> > motivation behind promoting undefined variable notices to exceptions: The
> > big pro
icular warning can occur as
part of nearly any operation. The additional complexities that arise when
you combine this problem with a JIT compiler are left as an exercise to the
reader.
Regards,
Nikita
t. The previous approach using static methods seemed more
natural to me, especially when it comes to operators that do not typically
commute (e.g. subtraction).
Regards,
Nikita
t me know what you think.
>
My main question would be how this will affect 3rd party extensions, which
are currently using autoconf. Will they need to migrate to cmake, or will
we have to effectively maintain both build systems?
Generally, I do think that migrating to cmake makes sense though.
Regards,
Nikita
he additional
> size of the PHP binaries which would result by linking it in, but if
> others are, we could still introduce a configuration option (e.g.
> `--with-libavifinfo`).
>
> Thoughts? Objections to bundling libavifinfo at all?
>
> [1] <https://github.com/php/php-src/pull/7711>
>
Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The
library is small, our avif functionality is incomplete without it, and we
can't expect this to be available as a system library at this time.
Regards,
Nikita
On Sat, Nov 20, 2021 at 11:37 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on https://wiki.php.net/rfc/github_issues. The vote
> closes 2021-12-04.
>
> Please see https://externals.io/message/116302 for the RFC discussion,
> and https://externals.io/
On Wed, Nov 24, 2021 at 1:41 PM Nikita Popov wrote:
> Hi internals,
>
> We're currently having some issues with CI, with both Travis and Azure not
> working, basically for the same reason (credits/parallelism for open-source
> projects got used up or expired). I've o
On Fri, Nov 12, 2021 at 2:07 PM Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
The RFC has been accepted with 52 votes in favor and 25 against.
Regards,
Nikita
On Fri, Nov 12, 2021 at 2:07 PM Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>
As a reminder, voting on this RFC closes tomorrow.
l be started again or if there
> are plans to disable Travis CI support ?
>
> Regards,
> Chandranana
>
Travis is working again.
Regards,
Nikita
il (Cirrus and AppVeyor
still work though).
Regards,
Nikita
ctions. The PHP project itself uses Travis CI for testing non-x86
platforms only, which are generally not available on other CI providers.
Regards,
Nikita
,
> };
> ?>
>
Isn't this equivalent to just this?
loadGermanLanguageSettings(),
default => loadDefaultLanguageSettings(),
};
'en_US' and 'en_GB' will already go to the default branch if they're not
listed explicitly.
Regards,
Nikita
early
feedback.
Regards,
Nikita
Hi internals,
I've opened voting on https://wiki.php.net/rfc/github_issues. The vote
closes 2021-12-04.
Please see https://externals.io/message/116302 for the RFC discussion, and
https://externals.io/message/114300 for the pre-RFC discussion.
Regards,
Nikita
then I'll plan on implementing #3 next Wednesday.
>
There's a draft page for the 8.1 announcement here:
https://github.com/php/web-php/pull/450
So if we want to do an announcement page for 8.1, there's probably not that
much work left in finishing that draft.
Regards,
Nikita
On Thu, Nov 18, 2021 at 2:53 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:
>
>
> On Thu, Nov 18, 2021, 7:32 AM Nikita Popov wrote:
>
>> On Thu, Nov 18, 2021 at 2:07 PM Patrick ALLAERT
>> wrote:
>>
>> > Le mer. 17 no
lly, it's not possible to make the issue and the whole
conversation around it public after the issue has been fixed.
Regards,
Nikita
passthru() and exec(), shell_exec() is the only function that
doesn't currently accept a $result_code parameter, so including it makes
sense for consistency.
Regards,
Nikita
On Mon, Nov 15, 2021 at 9:18 PM Björn Larsson
wrote:
> Den 2021-11-02 kl. 15:19, skrev Nikita Popov:
> > Hi internals,
> >
> > The migration from bugs.php.net to GitHub issues has already been
> discussed
> > in https://externals.io/message/114300 and has already
On Wed, Nov 17, 2021 at 5:35 AM Paul Crovella
wrote:
> On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov wrote:
> >
> > Hi internals,
> >
> > I've opened the vote on
> > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> > 2021-1
On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl wrote:
> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov
> wrote:
>
ally always been really bad at that. Of course, letting
someone else host it is incompatible with the desire to fully "own" our
data. I do appreciate the general sentiment here though.
Regards,
Nikita
On Tue, Nov 2, 2021 at 3:19 PM Nikita Popov wrote:
> Hi internals,
>
> The migration from bugs.php.net to GitHub issues has already been
> discussed in https://externals.io/message/114300 and has already happened
> for documentation issues.
>
> I'd like to formally pro
On Wed, Nov 10, 2021 at 10:06 AM Nikita Popov wrote:
> On Fri, Aug 13, 2021 at 3:28 PM Nikita Popov wrote:
>
>> Hi internals,
>>
>> I'd like to address a common footgun when using foreach by reference:
>> https://wiki.php.net/rfc/foreach_unwrap_ref
>>
On Fri, Nov 12, 2021 at 5:34 PM Nikita Popov wrote:
> On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey wrote:
>
>> > On Nov 12, 2021, at 10:10, Derick Rethans wrote:
>> >
>> > On 12 November 2021 13:07:42 GMT, Nikita Popov
>> wrote:
>> >>
On Fri, Nov 12, 2021 at 5:25 PM Ben Ramsey wrote:
> > On Nov 12, 2021, at 10:10, Derick Rethans wrote:
> >
> > On 12 November 2021 13:07:42 GMT, Nikita Popov
> wrote:
> >> Hi internals,
> >>
> >> I've opened the vote on
> >> http
Hi internals,
I've opened the vote on
https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
2021-11-26.
Regards,
Nikita
On Wed, Nov 10, 2021 at 10:13 PM Jeremy Mikola wrote:
>
>
> On Tue, Nov 9, 2021 at 4:30 AM Nikita Popov wrote:
>
>>
>> In
>> https://github.com/php/php-src/commit/a551b083073ea08f8fc53b0e1a6380b6de26cc6b
>> I've added a hack to add the string return t
On Wed, Nov 10, 2021 at 7:23 PM Niklas Keller wrote:
> Hey Nikita,
>
> I'd like to propose using HackerOne instead of bugs.php.net for security
> issues: https://www.hackerone.com/company/open-source-community
>
> Best,
> Niklas
>
Unfortunately I have no familiari
On Wed, Nov 10, 2021 at 5:51 PM Nikita Popov wrote:
> On Thu, Nov 4, 2021 at 5:58 PM Dan Ackroyd wrote:
>
>> On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote:
>> >
>> > I'd like to formally propose to use GitHub for PHP implementation
>> issu
On Thu, Nov 4, 2021 at 5:58 PM Dan Ackroyd wrote:
> On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote:
> >
> > I'd like to formally propose to use GitHub for PHP implementation issues
> as
> > well: https://wiki.php.net/rfc/github_issues
>
> In general, yes pl
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course)
On Fri, Aug 13, 2021 at 3:28 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to address a common footgun when using foreach by reference:
> https://wiki.php.net/rfc/foreach_unwrap_ref
>
> This addresses the issue described in the big red box at
> https://www
either. Personally, I would be fine with simply
dropping them, as they do add additional maintenance burden without any
apparent benefit. Maybe Dmitry has some thoughts on this.
Regards,
Nikita
0f972e0d4a11c89ce28d5768d9824d3
I have added a warning if this happens. The warning is only for master
(i.e. PHP 8.2) to make sure that extensions add the type eventually, and we
can drop this workaround.
Regards,
Nikita
t/rfc/github_issues
Regards,
Nikita
On Fri, Oct 8, 2021 at 4:16 PM Nikita Popov wrote:
> Hi internals!
>
> I've opened voting on
> https://wiki.php.net/rfc/deprecate_partially_supported_callables, which
> deprecated callables that are not supported in $callable() syntax. The vote
> closes on 2021-10-22.
&
On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka wrote:
> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov wrote:
>
>>
>> I'm proposing the following label structure (the list at
>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>> repor
On Sun, May 9, 2021 at 8:49 AM Joe Watkins wrote:
> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don&
k if the
> name of the function contains "{closure}", which is a bit unpleasant and
> depends on undocumented behaviour.
>
> I'm proposing the addition of ReflectionFunctionAbstract::isAnonymous(),
> which would fill this use case, and may be able to offer an implementation.
>
Sounds reasonable to me!
Nikita
On Wed, Oct 13, 2021 at 3:43 AM Tim Starling
wrote:
> On 12/10/21 9:23 pm, Nikita Popov wrote:
> > Based on the received feedback, I've updated the RFC to instead provide
> an
> > #[AllowDynamicProperties] attribute as a way to opt-in to the use of
> > dynamic proper
e using dynamic properties
without error. (That is, as usual: Deprecations are converted to error in
the next major version.)
Regards,
Nikita
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course)
Hi internals!
I've opened voting on
https://wiki.php.net/rfc/deprecate_partially_supported_callables, which
deprecated callables that are not supported in $callable() syntax. The vote
closes on 2021-10-22.
Regards,
Nikita
the general
pattern following the same rules. (This syntax has a special case that
should be deprecated: "${label}" will be interpreted the same as "$label"
instead, which is inconsistent with how it works everywhere else. This is
also why ${yield} without argument will not perform a yield and instead
look for a variable called $yield.)
PHP unfortunately doesn't have a general expression interpolation syntax,
you can only interpolate variables and certain variable-like constructs.
Regards,
Nikita
On Tue, Oct 5, 2021 at 4:08 PM Côme Chilliet wrote:
> Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a écrit :
> > If we make this change, I would however suggest to also support "false"
> as
> > a standalone type. I think this change primarily has be
On Tue, Oct 5, 2021 at 12:47 AM tyson andre
wrote:
> Hi Nikita Popov,
>
> > 1. There would be the possibility of having an interface Deque that is
> > backed by a VecDeque/ArrayDeque implementation. I'm not convinced this
> > would actually make sense, but I wanted
On Thu, Sep 2, 2021 at 4:32 PM Nikita Popov wrote:
> Hi internals,
>
> Currently, there are some callables that are accepted by the "callable"
> type, but which cannot be used with $callable() syntax. This RFC proposes
> to deprecate support for such "callables&
know how this will look like on a technical level (it
doesn't seem to be implemented yet?) This seems like something that will
require a check on every write operation, to potentially separate the
structure in some form.
5. The shift/unshift terminology is already used by our array API, but I'm
not sure it's the most intuitive choice in the context of a deque. SplQueue
has enqueue() and dequeue(). Another popular option from other languages
(which I would personally favor) is pushFront() and popFront().
Regards,
Nikita
On Thu, Sep 9, 2021 at 6:31 AM Go Kudo wrote:
> Hi Nikita, sorry for the late reply.
>
> This is a difficult problem. For now, MT19937 is left for compatibility.
> In other words, if you don't need compatibility, there is no benefit to
> using it.
>
> What about implem
ent of splitting up ext/standard into smaller
extensions, maybe he has some thoughts on this.
Regards,
Nikita
pe_digit() I only intended it to match [0-9]. It
seems like some people try to use ctype_alpha() in a locale-sensitive way (
https://stackoverflow.com/questions/19929965/php-setlocale-not-working-for-ctype-alpha-check)
and then fail because it doesn't support UTF-8.
Regards,
Nikita
PS: Rega
ortunately the syntax
options we have for this are not as nice as in other languages. [=> $x] is
probably the most reasonable choice where array literals are concerned.
https://wiki.php.net/rfc/named_params#shorthand_syntax_for_matching_parameter_and_variable_name
also has some thoughts on this topic, as named params have the same problem.
Regards,
Nikita
(object)[], you also can't write (int)X (but you can
write +X). I think it's perfectly reasonable to support casts in constant
expressions, and if we do, then I don't think we need to go out of the way
to forbid object casts either, so support for (object)[] should just fall
out as a special case.
Regards,
Nikita
t complication to the system (that users need to be aware of, and
consumers of the reflection API need to handle) for what ultimately seems
like a personal style choice to me. Do you have any examples where using
static factories over constructors for attributes would be particularly
compelling?
Regards,
Nikita
- the spam problem (both link
spam and actively malicious users) is part of the motivation to switch to
GitHub Issues (which requires authentication and thus can be moderated
effectively).
Regards,
Nikita
reflection and need to be handled appropriately.
I am fine with additions as Tyson suggests them: Methods that work across
*all* ReflectionTypes. The proposed methods do not fall in this category,
as they don't hold up for intersection types in PHP 8.1 already, let alone
future type system additions.
Regards,
Nikita
support "false" as
a standalone type. I think this change primarily has benefits from a
typesystem completeness perspective rather than a strong practical need.
>From that angle, it would be nice if all types that are usable in a union
are also usable as standalone types, rather than shifting the special case
from null to false.
Regards,
Nikita
ions is actually a major implementation pain,
as well as a big performance concern) and would make minor version upgrades
for libraries much simpler. However, it also removes the ability to address
problems before they turn into fatal errors, e.g. by recording any stray
deprecation warnings in production. There was certainly a big outcry over
the handful of backwards-incompatible changes in PHP 8.0 that did not
previously trigger deprecation warnings.
Regards,
Nikita
On Thu, Sep 23, 2021 at 4:10 PM Nikita Popov wrote:
> On Wed, Sep 15, 2021 at 7:23 PM Jeremy Mikola wrote:
>
>> I just discovered that run-tests.php was changed to cache SKIPIF
>> evaluation
>> since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as
>&g
etup as the actual test. If the test does get
skipped, it's still fine to cache that.
Now, it sounds like your situation is different from that, and you actually
have SKIPIF sections where first one test should be skipped, but then a
later test with identical SKIPIF shouldn't be skipped. Is that correct?
What changes between the time these two tests run?
Regards,
Nikita
we will accept an option
(whether that be an ini option or something else) to control this behavior.
We can make the change or not make it, but not both ;)
Regards,
Nikita
habricator.wikimedia.org/T291234>. The
> UTF-8 locales mostly work, except for the Turkish ones, which mangle
> ASCII strings.
>
> At https://bugs.php.net/bug.php?id=67815 , Nikita Popov wrote: "My
> general recommendation is to avoid locales and locale-dependent
> funct
ing a proper "type", so should it be in the type system?) but I can see
the practical usefulness, so I think it's worth discussing this.
Regards,
Nikita
On Mon, Sep 6, 2021 at 6:50 PM Kamil Tekiela wrote:
> Hi Nikita,
>
> I think this might be a good idea, but I would like to propose yet another
> variant.
> Replace stdClass with DynamicObject and keep stdClass as an alias. It can
> be deprecated in 8.3.
> If we only add
ached with a 100% cache hit rate (minus the first stat/lstat calls).
>
> Technically, yes, it's slower, but I'd suggest that making 2 million stat
> calls to a single file is a bad idea. And remember, the cache holds *one*
> file. If you stat a second file it's a cache miss.
>
These numbers look pretty good to me. It would be great if someone on
Windows and macos could repeat this experiment, so we have an idea of how
other platforms fare in this worst-case scenario.
Regards,
Nikita
ttps://github.com/apple/swift/pull/39143 is entirely divisionless.
Doing this would improve performance (though I'm not sure by how much --
maybe once we add up our call overhead, it isn't important anymore?) but it
would provide a different sequence than mt_rand(). Something we might want
to consider.
Regards,
Nikita
ttle
sense. $random->getInt($n) could be interpreted either as a number in
$n..PHP_INT_MAX (if we just see it as leaving $max at the default value),
or 0..$n-1 (a very common convention for single-argument random integer
functions). Requiring both arguments makes the meaning unambiguous.
Regards,
Nikita
that it is the return type of
casting an array to (object).
The actual role of stdClass is to serve as a container for dynamic
properties, thus the suggested DynamicObject name.
What do people think about adding such an alias? Is this worthwhile?
Regards,
Nikita
h is O(1). Userland would have to call array_keys()
first to allow random access on keys, which is O(n).
Which is why I think this is a good addition to php-src. There's three good
reasons to include functionality in php-src (performance, ubiquity and FFI)
and this falls squarely into the first category. And now that we have
fibers and need to worry more about multiple independent execution streams,
we also need to worry about multiple independent randomness streams.
Regards,
Nikita
e scope mentions: "Changes random source to php_random_int() a
shuffle(), str_shuffle(), and array_rand()". I don't think it makes sense
to switch these functions to use cryptographic randomness by default...
Regards,
Nikita
Content-Length field - it will almost certainly be wrong.
>
Just to throw it out there: Maybe we should clear the stat cache when
functions in the exec family are used? Even if we allow disabling the stat
cache, I think we can easily avoid that particular footgun. And if calls to
external binaries are involved we likely don't have to worry about stat
overhead.
Regards,
Nikita
1 - 100 of 2242 matches
Mail list logo
