>
> Hi,
>
> What do y'all think about requiring GPG signed commits for the php-src
> repository?
>
> I had a look, and this is also something we can enforce through GitHub
> as well (by using branch protections).
>
> cheers,
> Derick
>
>
> --
> https://derickrethans.nl | https://xdebug.org |
>
> 2024年3月9日(土) 15:26 youkidearitai :
> >
> > Hello, Internals
> >
> > I created an wiki for `grapheme_str_split` function.
> > Please see:
> > https://wiki.php.net/rfc/grapheme_str_split
> >
> > I would like to "Under Discussion" section.
> >
> > Best Regards
> > Yuya
> >
> > --
> >
>
> Hi Internals,
>
> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is understandable.
>
> In particular, I am looking for any feedback as to why this is a bad
> idea. The primary
>
> Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support
>
> First time, so I'm not surprised if there are some mistakes there.
>
> Feedback is very welcome.
>
Hi Hans,
The RFC looks great, and I am personally positive to see these proposed
changes implemented in PHP.
One
>
> just like the constructor accepts
> new DateTime("@0.123456"); // 1970-01-01 00:00:00.123456
> new DateTime("@".microtime(true));
>
> IMO setTimestamp should accept the same:
> $dt->setTimestamp(0.123456); // 1970-01-01 00:00:00.123456
> $dt->setTimestamp(microtime(true));
>
> Can we change
> > I see. I'll change mb_ucfirst using titlecase.
>
> Per my comments a month ago on the GitHub issue , I think it is much
> better to use title case for mb_ucfirst() than to use upper case,
> since conversion of the first character to upper case has the effect
> of corrupting text in the
>
> On Fri, Feb 2, 2024 at 2:00 AM youkidearitai
> wrote:
>
> > Hi, Internals
> >
> > I have just opened the voting "Multibyte ucfirst and lcfirst functions"
> > RFC.
> > https://wiki.php.net/rfc/mb_ucfirst
> >
> > Voting will be open until February 26th, 2024 at 01:00 UTC.
> >
> > Cheers
> >
>
> I just encountered this language inconsistency when trying to remove
> nullable from a constructor-promoted property:
>
> ```
> class MyClass
> {
> public function __construct(
> public ?string $title = null // removing "?" here causes "Fatal
> error: Cannot use null as default
>
> There could be OOP-style alternatives too, e.g. Rust has a PathBuf struct
> with methods that are used to build paths.
> However if we were to choose this route then we need to be aware that
> interoperability with existing filesystem functions would be much harder
> because they all work
> Shift_JIS is very ambiguous, What will we do if SJIS-2004 or SJIS-win comes?
> How do we guess(detect) SJIS-2004, SJIS-win and SJIS-mac?
I'm not the person you replied to in your previous email, but I
thought to weigh in with what I can. My native language also uses
multiple bytes, and have
>
> try {
> // do stuff
> } catch(Throwable $exception) {
> $this->logger->error("failed to do stuff", compact('exception'));
> throw $exception;
> }
>
I wonder why not just create an array with the key...
```php
try {
// do stuff
} catch(Throwable $exception) {
>
> Hi,
>
> > In the latter case, I suppose they would expect the behaviour to be
> > compliant with the database standards.
>
> I may not have had this perspective. And this is a strong basis for
> explaining that different drivers behave differently.
>
> I will continue with the current
> More importantly, it is possible to write cross compatible code, even
> without changing anything about is_resource(), if we convert streams to
> opaque objects.
> It might be tedious and one might need to have redundant instanceof checks
> with is_resource() if one does not want to check for a
>
> Hi internals,
>
> As shown in the following issue, the behavior of `PDO::PARAM_` is
> inconsistent and I would like to fix this.
> https://github.com/php/php-src/issues/12603
>
> First, I tried fixed pdo_pgsql.
> https://github.com/php/php-src/pull/12605
>
> Eventually I plan to make
>
> PHP lacks two very basic functions for working with arrays:
>
> - array_first() returning the first element of an array (or null)
> - array_last() returning the last element of the array (or null)
>
> While PHP has functions that return the first and last keys,
> array_key_first() and
> > ext/imap
> >
> > The library that provides the functionality in this extension, c-client,
> > is no longer updated. The last release from 2007 is no longer available
> > on the original distributor's (University of Washington) website, but
> > there is an unofficial GitHub repository that
> whether returning boolean is the right thing to do at all. It seems obviously
> intuitive it should, returning true for valid and false for invalid JSON
> but then if you consider you're still going to be in the situation of
> calling json_last_error() if you want to know why invalid JSON was
Awesome, thanks a lot for this.
On Mon, Jul 11, 2022 at 1:50 AM Nikita Popov wrote:
>
> On Sun, Jul 10, 2022 at 10:07 PM Ayesh Karunaratne wrote:
>>
>> Dear Internals,
>> Historically, we have been using Travis CI for our automated tests,
>> but since 2021
Dear Internals,
Historically, we have been using Travis CI for our automated tests,
but since 2021 June, travis-ci.org has ceased operations, and no
longer runs any builds. There was an Internals discussion
(https://externals.io/message/112709) to move to the successor,
travis-ci.com, but I don't
With php-src's recently starting to Github Actions, would it be
possible for PECL builds to use Github Actions with Windows. It
supports Windows server 2016, 2019, and even 2022 (IIRC).
On Fri, Apr 8, 2022 at 5:17 PM Christoph M. Becker wrote:
>
> Hi all,
>
> bad news: the Windows PECL build
Hi Tim,
Thank you for opening the discussion. I personally find this feature
useful, and glancing at the diff, it looks like a rather
straightforward and minimal change.
FWIW, it is possible to selectively expose class properties in a class
object being `var_dump`-ed with the `__debugInfo` magic
>
> Hi all,
>
> a while ago it has been reported[1] that our header() function actually
> allows arbitrary status codes, which may even overflow. Of course, that
> makes no sense, since the status code is supposed to be a three digit
> code. So this ticket has been followed up by a pull
Hi Nikita,
Thank you so much for what you have done for PHP, the language and the
community we all are in. I can't muster enough words to say how
grateful I am to you for all the changes we have in PHP all these
years. From every commit I see from you, to every podcast I listen to,
from every PR
es,
> > etc. I have added support for a static list that maps git.php.net
> > names to GitHub repo under `php` organization namespace.
> >
> > oh i see.
> >
> > fwiw, your implementation looks more professional / enterprise-y :)
> >
> >
> > On Tu
> here is an initial implementation:
> https://github.com/divinity76/git-php-net-redirector/blob/main/src/redirector.php
> it is just a minimum-effort implementation, anyone feel free to make
> something better (also i have no idea how the "p" argument is supposed to
> be parsed, so i just
>
> 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):
>
> https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> This has been discussed in various forms
> I agree about the _string suffix removal. However, I know we have
> parse_url() already, but parse_query() might be too generic. I would
> suggest adding "http" to the name. And as we already have
> http_build_query() I would rather see http_parse_query().
>
+1 for http_parse_query() as it
>
> Hello!
>
> This is my first RFC proposal. I have an idea about introducing autoconst
> keyword.
> Motivation:
> reduce duplicated code (copy/pasting constant name as value)
> reducing potential typo errors in constant values
>
> instead of defining constants like:
> const FOO = 'FOO';
>
>
> Greetings internals,
>
> I present to you a proposal for a new basic math function: clamp.
>
> The main goal of this function is to contain a number inside a given bound.
> And return the number if it is inside of that bound, and if not, and the
> number is outside of the given bound, the
>
> Den søn. 6. jun. 2021 kl. 00.09 skrev Ayesh Karunaratne :
> >
> > Hi Ben,
> > Thank you for opening this PR and the discussion. With the wide
> > availability of AVIF/AV1 support in browsers, I think this will fit
> > nicely.
> >
> > We have the
Hi Ben,
Thank you for opening this PR and the discussion. With the wide
availability of AVIF/AV1 support in browsers, I think this will fit
nicely.
We have the Namespaces in Bundled Extensions RFC
(https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so
perhaps, the new functions
Hi Timon,
Thank you for this RFC. I think the `string|int $indent` approach is great !
Reading the PR, it looks like `$indent=0` is essentially turning off
pretty-print, which I think is intuitive.
Do you plan to add any sort of validation on negative integers?
Perhaps throw a `\ValueError`
>
> Hi Nikita,
>
> wt., 11 maj 2021 o 10:53 Nikita Popov napisał(a):
>
> > Hi internals,
> >
> > I'd like to propose the depreciation of the ticks mechanism:
> > https://wiki.php.net/rfc/deprecate_ticks
> >
> > I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> > is a
Hi Michael,
Thanks for opening this conversation and the PR.
Most HTTP client libraries that need to set a custom user agent do so
with `curl_setopt` because it needs to contain a library version or
some sort of dynamic values. They will likely not benefit from this
change. On the other hand,
I think this is a great step forward.
With commit signatures required, I think the person who merges a PR
now needs to do so locally. [GitHub CLI](https://cli.github.com/)
helps me a lot to locally checkout a PR quickly, and then
rebase/squash with my own signature.
Thanks to Levi Morrison and
Larry already mentioned `auto_append_file` that I also think is the
way to go, if it fits.
The example directory structure from your email is also considered
insecure, because without proper web-server protection, you are
essentially exposing _all_ `vendor` files, including the ones that
Thank you for opening this conversation, these functions have stung me
in the past, and I would be so happy to see them gone :)
Personally, I would very much like to go with Plan A.
- XML parsers that often deal with non-UTF-8 character encodings
frequently use these functions. However, any
Please ignore my last message :(
Hi Internals,
I did a somewhat rough test to compare Composer's autoloader and the
function proposed in the RFC.
## TL;DR:
autoload_set_classmap over Composer with OPCache: 8.12%
autoload_set_classmap over Composer without OPCache: 7.93%
## Long version:
38 matches
Mail list logo
