Why not just add structs at this point? It's almost like we don't want to
acknowledge that structs are a thing.
On Wed, 4 Sept 2024 at 15:07, Christoph M. Becker wrote:
>
> Hi all,
>
> that issue came up the other day on a pull request[1], but since it is
> not particularly related to any single PR, I wanted to ask here for
> clarification.
>
> This is about changes to `./configure` options of php-src, and
On Mon, 26 Aug 2024 at 20:05, Calvin Buckley wrote:
> As such, it might be a bit tricky for people on Windows/AIX; the easiest
> solution if PHAR is using the openssl extension's symbols would be to not
> build the openssl extension as shared.
I've just checked Windows build and the PHP downloade
Hello,
There came up another idea/issue about the Phar extension and its
native SSL support.
As you might know or not, when building PHP:
./configure --with-openssl --enable-phar
the Phar extension will get so-called native SSL enabled through
OpenSSL directly. However, when built like this:
.
On Tue, 13 Aug 2024 at 01:57, Juliette Reinders Folmer
wrote:
>
> Hi all,
>
> I suppose everyone is aware of 3v4l.org and a lot of us use it on a regular
> basis.
>
> 3v4l also auto-builds the PHP "master" branch every night to allow for
> testing with the latest and greatest PHP version and com
On Mon, 5 Aug 2024 at 19:15, Christoph M. Becker wrote:
> But what about other compilers we support on non Windows platforms
> currently, like clang, Apple's clang, Solaris Studio and maybe some more
> we don't even know about.
Might be worth noting here that from what I've tested so far that PHP
The deprecation arguments seem almost academic to me.
Thanks,
Peter
developers are positively surprised by PHP's modern features. But
can we blame them for being surprised if these are the top tutorials out
there?
Deprecating these functions isn't addressing the core issue. The focus
should be on making it easy for new learners to access up-to-date tutorials.
Thanks,
Peter
On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman wrote:
> If their learning insticast
>
*instincts.
I should also clarify, I'm not against deprecations in general. However,
the benefits should outweigh the costs. If something is getting
unmaintainable, no longer supported, inherent
oint, and
applies to sha256 just the same. You want to be able to hash the same
content and get the same hash. Just the complexity and chance of
collision changes. The reliability and security you are concerned with in
this scenario really depends on what randomness you feed it.
Thanks,
Peter
e.
Lots of effect with little gain. The warning in the documentation should
be sufficient.
Thanks,
Peter
krakjoe) would be a good person to ask, he's worked on that
and he also did pthreads and parallel. But I'm not sure how active he is
anymore. Gina Banyard (Girgias) or Niels Dossche (nielsdos) will probably
know too.
You can try to ping them in https://chat.stackoverflow.com/rooms/11/php
Thanks,
Peter
024 to use md5 and sha1.
Granted hashing passwords isn't one, but we're past that as a community
already. And for the few that aren't, I'd argue there is no saving.
Thanks,
Peter
On Thu, 18 Jul 2024, 16:32 Ilija Tovilo, wrote:
> Hi Christoph
>
> On Thu, Jul 18, 2024 at 2:09 PM Christoph M. Becker
> wrote:
> >
> > So I suggest to sync CODEOWNERS for all active branches (and maybe even
> > security branches).
> >
> > What do you think?
>
> I think back when it was introduc
Hello,
There is another pull request in preparation that I'd like to squeeze in
the PHP-8.4 branch if it will possible to wrap it up until the feature
freeze milestone:
https://github.com/php/php-src/pull/13755
In short, pkg-config is *nix command line utility to query installed
libraries on the
allows for
visibility control at the boundary, so I can hide implementation classes
within the module and control the public interface.
Peter
Hello,
Perhaps you're not aware that the PHP build system currently still
supports building apache2handler SAPI for Apache 2.0 and 2.2 branches.
Apache 2.2 has been marked as EOL in December 2017 and doesn't receive
security patches. Also, most Linux distributions and packages mostly
support 2.4 a
On Mon, 17 Jun 2024 at 19:16, Matteo Beccati wrote:
>
> Hi,
>
> Il 17/06/2024 19:03, Peter Kokot ha scritto:
> > On Mon, 17 Jun 2024 at 18:58, Pierre wrote:
> >>
> >> Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via
> >> PHP (PDO
On Mon, 17 Jun 2024 at 18:58, Pierre wrote:
>
> Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via
> PHP (PDO or ext-pgsql) ?
>
> If so, it might be a dangerous move for oldest projects, you sometime
> can upgrade PHP and your software easily, but can't upgrade the database
> s
Hello,
we're thinking of bumping the minimum PostgreSQL version supported by PHP from
current version 9.1 to version 10.0:
https://github.com/php/php-src/pull/14540
A list of PostgreSQL versions and their EOL dates can be seen at
https://en.wikipedia.org/wiki/PostgreSQL
The versions coverage by
)`, but doesn't. Take a look:
https://3v4l.org/aPCSD
I found it at the bottom of the manual entry for Strings[1]. Not something
I would use, but it's interesting to see.
Thanks,
Peter
[1]: https://www.php.net/manual/en/language.types.string.php#91628
Hello,
I was wondering if it would be useful to add GitHub milestones for the
PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestones
Because some pull requests might target versions after the PHP-8.4 and it
might be useful to have them additionally sor
On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote:
>
> Hi, Internals
>
> Sorry I mistake.
> Send again.
>
> grapheme_str_split going to "Voting" phase.
> Vote end is 10th April 00:00 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.inf
On Tue, 5 Mar 2024 at 01:27, wrote:
>
> > The VSC part from github (hosting our code), can very easily be ported.
> > Issues, discussions etc can not.
> >
> > With the ongoing enshittification of most of the Internet due to
> > advertising and tracking, we'd be negligent not hosting and owning o
On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo wrote:
>
> Hi Yuya
>
> It seems you accidentally sent your response to me instead of the list.
>
> On Sun, Feb 11, 2024 at 5:10 PM youkidearitai wrote:
> >
> > 2024年2月11日(日) 21:18 Ilija Tovilo :
> > >
> > > Hi everyone.
> > >
> > > I would like to start
On Thu, 2 Nov 2023 at 05:02, Christopher Jones
wrote:
>
> On 2/11/2023 2:46 am, Derick Rethans wrote:
> > Hi,
> >
> > I have just opened voting on the RFC to unbundle imap, pspell, and
> > oracle integrations.
>
> :)
>
> --
> https://twitter.com/ghrd
>
> --
> PHP Internals - PHP Runtime Developme
On Tue, 5 Sept 2023 at 11:40, Hanz wrote:
> Hello,
>
> Ran into a couple of issues with RC1 that I haven't seen online.
>
> With --with-pear: The --with-pear option is deprecated
>
> With --enable-pear: configure: WARNING: unrecognized options: --enable-pear
>
> I'm using --disable-all as the fir
On Mon, 14 Aug 2023 at 16:18, G. P. B. wrote:
> Hello internals,
>
> While working on some DNF type bugs, I discovered some major issues around
> the disable_classes INI setting implementation. Such as:
>
> - A double-free of the type of a typed property
> - A use after free (which segfaults) whe
On Tue, 11 Jul 2023 at 13:37, Levi Morrison wrote:
>
> On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote:
> >
> > Chatter on the [Interface Default Methods RFC][1] has been quiet for
> > the past 6 days, and the feature freeze deadline is fast approaching
> > for PHP 8.3, so I'm moving this to v
On Fri, 28 Apr 2023 at 12:01, Jakub Zelenka wrote:
>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub
It would be also good to know why people vote no.
--
PHP Internals - PH
On Wed, 12 Apr 2023 at 15:53, Alex Wells wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely work
ps://github.com/kambo-1st/ipc-duckdb-ffi-extension-workshop /
presentation
https://docs.google.com/presentation/d/1_hGrKsJey9YvFMGrKk34p_hRmfPU4swiaUhCpVygVjo/edit.
That might be manageable to complete.
I won't be stepping up to work on FFI because IMO that requires more
experience than I can bring - in extension writing, and particularly in
using FFI and knowing its strengths and pitfalls inside-out. For keeping
track of what I and others find while using FFI, is this mailing list or a
GitHub issue the best place to record it?
Peter
hopes for it - but in my experience it doesn't feel finished. php-vips is
the biggest example of using it that I've seen.
Peter
the
benefits of native extensions will often be what's needed instead of FFI.
Peter
On Wed, 22 Feb 2023 at 14:14, Max Kellermann wrote:
>
> On 2023/02/22 13:45, Max Kellermann wrote:
> > 13 years ago, there was commit
> > https://github.com/php/php-src/commit/477649cd3f09 which attempted to
> > fix this, but was reverted on the same day by commit
> > https://github.com/php/php-s
On Sun, 12 Feb 2023 at 09:31, Max Kellermann wrote:
>
> On 2023/02/11 17:14, Peter Kokot wrote:
> > I've voted in favor of the RFC because of the code-cleaning,
> > tech-debt-reducing improvements to code readability.
>
> Exactly my point, and I'm surpris
On Wed, 1 Feb 2023 at 13:14, Max Kellermann wrote:
>
> On 2023/01/30 11:26, Max Kellermann wrote:
> > If nobody objects, I'll announce the start of voting on February 1st.
>
> That's today.
>
> Voting starts now, please vote on my RFC:
> https://wiki.php.net/rfc/include_cleanup
>
> Original disc
mented in future (9.0?) but now agree that 8.3 isn’t the right place.
Peter
On Sat, 10 Sept 2022 at 11:32, Yasuo Ohgaki wrote:
>
> 2022年9月7日(水) 22:58 Misha :
>
> > Hello everyone,
> >
> > We spend a lot of time to increase limits for uploads file in PHP. Can we
> > increase it in php.ini?
> >
> > Current value is 2Mb. Its so small value, when photo image can take 8Mb on
>
which I had overlooked. Does an exception make most
sense when this happens?
Peter
x27;m not convinced JSON_THROW_ON_ERROR belongs here. I can't
think of a case where more than a boolean response is needed.
Peter
On Tue, 23 Aug 2022 at 19:09, David Gebler wrote:
> I can just see floor_div and floor_mod getting mixed up
> with fdiv and fmod but maybe I'm overthinking it, maybe it wouldn't really
> be an issue. Maybe there's alternative names you could give them though
> again I suspect the ones you've chos
er, behave identically to now.
The "Unaffected PHP Functionality" section only muddied the waters further:
"Normal usage ... of the json_encode function will not be affected, as
the default of 4 spaces will still be in effect."
My point being, I don't think this document was anywhere near ready... but
feel free to disagree.
Just to finish up, wouldn't it be nice to have the following?..
json_encode($value, indent: 2)
Regards,
Peter
On Wed, 8 Jun 2022 at 20:16, shinji igarashi wrote:
> > declare(ignore_newline_after_close_tag=false);
>
> Thanks for coming up with another idea!
>
> As others have already pointed out, disabling the closing tag from
> eating trailing newline throughout the file would be inconvenient if
> we wan
27;t entirely removed it, and left a footgun for people
with a new special case that isn't variable interpolation and isn't normal
characters in a string.
Peter
$out[$docId]['labels'][$row['document_rejection_reason_id']] =
true;
}
Naturally I would prefer to keep this behaviour for arrays.
Peter
all the places
> that are covered by the claimed rationale".
>
> [snip]
>
> None of this is even mentioned in the RFC, let alone justified.
>
I have voted no for the same reasons.
Peter
re are unresolved discussions that have been going on since at least
2019 [1] about direction and what PHP should become. With the formation of
the PHP Foundation I hope these can be revisited.
Peter
References:
1. https://externals.io/message/106453
e was
different when classes were introduced to PHP. But dynamic properties have
been around since the start and I am wary of deciding to remove them in PHP
9.
Kind regards,
Peter
ic properties stays in the language but toggled off/on per class?
Peter
>
oss a range of array sizes, I'm strongly
in favour as I write this a lot.
Peter
t think that the comments by
> Larry/Chris/Pierre in this email thread are representative of voters.
>
Both.
I object to the name for what's being proposed, but am not necessarily
against what's being proposed if it looks more useful than the Spl* stuff.
I'm fine with the name b
of the discussion so far
has been around whether it's a Vector or what it should be; changing the
proposed name will allow the discussion to focus on what you're proposing
to add, not what others (myself included) would like to see added to PHP :)
Peter
en by the stat cache before and would be pleased to see it
gone for good.
Peter
On Mon, 9 Aug 2021 at 18:48, Jordan LeDoux wrote:
>
> You claim that this would be documented on php.net and this would be
> sufficient. Yet the DateTime class has had operator overloads for
> comparison operators since 5.2 and there is still *zero* mention on
> php.net
> (that I am aware of or c
been an annoyance, as
some querystrings use '.' to denote an array, in the way PHP chooses []. So
foo.bar would mean foo[bar] in PHP-speak.
The third I won't comment on as I don't know the Url algorithm.
Peter
>
> On Jul 6, 2021, at 08:34, Daniel Beardsley wrote:
Voting will be open till 2020-07-21
>
This date has passed, yet the vote is still ongoing.
Daniel, could you please close the vote and do the usual follow up tasks?
If Daniel is unavailable, what is the process for *someone else* doing
thos
is. Can someone who knows the PHP group
procedures please tell me the next steps?
Peter
ow (July 2021) is pretty unexpected.
Kind regards,
Peter
On Tue, 6 Jul 2021 at 10:47, Daniel Beardsley wrote:
> I've moved my RFC to the voting phase.
>
> Voting will be open till 2020-07-21
>
> https://wiki.php.net/rfc/pdo-mysql-get-warning-count
>
> The pull request (wi
On Mon, 28 Jun 2021 at 17:08, Larry Garfield wrote:
> Javascript doesn't have it natively, but there are 3rd party libraries
> that try to do it.
>
There is a proposal to add it to the language:
https://github.com/tc39/proposal-partial-application
Peter
wrapped function
calls).
I am a little ambivalent as I do feel the RFC's complexity has grown - I
would be happy without the variadic placeholder being included if it's a
choice between no partial function application or placeholders only. But if
I don't want to use variadic placeholders, hey I can omit them from my code.
Peter
please trim the emails they're quoting, it makes it
easier for readers to focus on what's being discussed in emails.
Thanks,
Peter
st a more welcoming place for newcomers.
I doubt "bottom posting" is a term people who started online in the last 10
years know - with today/yesterday's example, my takeaway was the original
poster didn't know what it meant. There's also English familiarity to
account for.
Peter
the existing
> void mistake and feels off, given that other recent changes to PHP have
> been more bold, towards removing inconsistencies.
>
This and Levi's email make compelling arguments and I would like to see
this adopted. I have changed my vote to "No".
Peter
Aw, my `terminus` suggestion didn't make it. ☹️
Thanks,
Peter
iscussion:
https://externals.io/message/38290
Thanks,
Peter
back that could be
> invoked inside a throw-aware buffering helper.
>
Hi Mark,
Have you considered using an array or DTO to pass the data?
You could also do this (although I'm not advocating it):
```
$vars = get_defined_vars();
$x = function() use ($vars) {
extract($vars);
/* ... */
};
```
Thanks,
Peter
: int
{
$val = $a + $b;
return $val + $c;
}
}
```
The Short class is "fine", but I would still prefer the Long class.
Thanks,
Peter
ession style" argument?
Overall, I'm not really that much against it, but my only worry is that
while it is slightly less verbose it might create more cluttered code.
Thanks,
Peter
P.S. I also don't like PSR-12. Allman braces and tabs for life.
On Mon, 22 Mar 2021 at 18:23, Guilliam Xavier wrote:
>
> On Mon, Mar 22, 2021 at 5:23 PM G. P. B. wrote:
>
> >
> > The thing is that by my recollections votes have already been extended.
> > Mostly when there has been issues with the mailing list, or some outside
> > event.
> >
> > Moreso, I don'
s with it. But
it is only dangerous if you use it without knowing what you are doing.
Thanks,
Peter
's already the same
> now, so if it's an issue it's not a new one with this RFC.
>
> It is a new issue. Today, interruptible functions must include a
> `yield` statement, so they are explicitly interruptible.
>
No, they don't need to yield. You can do `$guzzleClient->requestAsync()`
today, so how is it different?
Thanks,
Peter
y the same now,
so if it's an issue it's not a new one with this RFC.
Your average unaware developer can continue to happily use any libraries
they want without encountering any async issues. The calls from outside
the library will still be blocking, as PHP will still be single threaded.
Thanks,
Peter
Hello everyone,
I'm just adding a few cents into this discussion.
I've voted "yes" because we don't have any other async stuff RFCs available
nor in the preparation. PHP needs such functionalities very badly and very
quickly to sort of speak. Adding a brand new extension in the core is maybe
a s
On Sun, Mar 14, 2021 at 6:34 PM Peter Stalman wrote:
> Would it make sense to have both options?
>
6) Multiple decorators on the same function?
One problem with the wrapper pattern is that if you have multiple
decorators then wouldn't that end up calling the function multiple times?
$args);
return call_user_func_array($callable, $args);
}
}
```
Thanks,
Peter
bar($a, $b) { ... }
#[Timer('Bob')]
public function baz($a, $b) { ... }
}
```
Thanks,
Peter
On Sat., Mar. 13, 2021, 15:04 David Gebler, wrote:
> Decorators are a way of bringing aspect oriented programming into PHP core,
> yes, among other uses. Go AOP is a fairly bul
Hi David,
This sounds a lot like Asect Oriented Programming. Have you looked into
that?
PHP framework:
https://github.com/goaop/framework
PECL extension:
https://aop-php.github.io/
Thanks,
Peter
On Sat., Mar. 13, 2021, 08:51 David Gebler, wrote:
> With the introduction of attributes
On Wed., Mar. 10, 2021, 22:59 Sebastian Bergmann, wrote:
> Am 11.03.2021 um 07:51 schrieb Peter Stalman:
> > I like this RFC, but I'd like to see the RFC cover if any other languages
> > have a similar return type.
>
> The RFC has a "Prior art in other interprete
urn type.
The definition of `void` is that it has no return value, so I too agree
that the keyword `noreturn` is too close in meaning to `void`.
I'd also like to throw the word `deadend` or something similar into the
ring, to make things a bit clearer.
Thanks,
Peter
ee anything that is specific to amphp, not anything to limit it to
their use. Fibers also exist outside of PHP, while amphp doesn't.
Thanks,
Peter
ay of doing async, but it worked everywhere. Fiber allows that to
be much more convenient in switching contexts deep inside a call stack. I
don't think it needs to be the end-all-be-all coroutine solution to rival
Goroutines, and I'm pretty sure it's not trying to be.
Thanks,
Peter
Here we go again! Looking at you, attributes syntax.
Seriously though, any of `this`, `active`, `current`, or even `Fiber::self`
are fine with me.
You might have the same issue with that last one.
Thanks,
Peter
On Mon., Mar. 8, 2021, 14:57 Larry Garfield, wrote:
> On Mon, Mar 8, 2021,
antiating
> mysqli class". This IMHO downplays the impact for people hosting legacy
> code.
>
> Also: If there would have been an intermediate PHP version with default
> MYSQLI_REPORT_ERROR I would have voted "Yes", but in the current form I
> have to say "No".
>
I voted "No" for the same reasons.
Peter
first N/2 and the last N/2. Objects often show very little
that's useful.
Do you know of any research or writeups as to what works best - or even
saved output of how various REPLs show their output?
Peter
ain fiber: ", $value, "\n"; // Output: After
resuming main fiber: Test
Btw, this is just me vomiting my thoughts, I don't know enough about fibers
to design it one way or the other, but I hope to understand it more as well
as give a few different perspectives on it.
Thanks,
eneous) care about having string
> values. In this case, I highly prefer having explicitely written
> (de)hydration code than automatic magic values happening over the place.
>
I agree.
Peter
hem.
>
Tangentially, can this be considered a bug in FPM's handling? I appreciate
the speed boost FPM brought over CGI, but the more I work with it the less
I like the way it functions (but that is a separate conversation).
Peter
am merely curious. Thank you for
pushing this forward, as async is something PHP has been lacking and should
have IMO to compare favourably to other alternatives that do.
Regards, Peter.
On Thu, Dec 17, 2020 at 8:30 AM Aaron Piotrowski wrote:
> Hello everyone!
>
> I would like to i
arketing, and I would like
the content to address the objections from naysayers online who start by
saying "I haven't used PHP since PHP 4/5 and I wouldn't use it because..."
Can any firms that support PHP donate a copywriter or marketing executive
to help?
Peter
On Tue, 1 Sep 2020 at 08:59, Marco Pivetta wrote:
> Did the namespaces ship sail forever? Can we just have those instead,
> please?
>
To mix metaphors: it sailed, shot down in fiery flames.
Unfortunately.
Peter
t provides enclosure with the arg list ().
>
I read a lot of code I didn't write, and I like your example. It is much
more readable and self-documenting.
Peter
renaming is not used) than it is with the delimiter syntax.
> Sorry to everyone for causing this hazzle.
>
These things happen. Thank you for taking on-board the feedback and working
on the RFC.
Peter
tribute delimiter syntax would have
short-circuited much of this discussion.
> Then the secondary votes can be on the preferred block syntax.
> Voting no means to keep @@ (unless there's another RFC for voting to
> change that for another syntax without ending delimiter).
>
+1.
Peter
@[JoinColumn("Group_id", "id")],
> )]
> private $groups;
>
> < "User_Group",
> <>,
> <>,
> )>>
> private $groups;
>
> @:JoinTable(
> "User_Group",
> @:JoinColumn("User_id", "id"),
> @:JoinColumn("Group_id", "id"),
> )
> private $groups;
>
Good catch.
Peter
are various syntaxes in PHP with no ending symbols (`clone`,
> `public`, `yield`).
> (I doubt changing this will make a difference since many people prefer
> `#[]`/`@[]` for other reasons,
> but still consider that sentence to be misleading.)
Agreed.
Peter
On Mon, 10 Aug 2020 at 15:41, Peter Bowyer
wrote:
>
>
> On Mon, 10 Aug 2020 at 14:59, Derick Rethans wrote:
>
>> I did answer that as a reply to Rowan:
>>
>> https://externals.io/message/111312#111346
>
>
> I'm with Rowan's response to you:
>
parentheses giving:
<><>(
<><>(<>),
42
)
and:
<>[<>(
<>[<>(<>)],
42
)]
in terms of parsing, use etc.
Peter
nd
why () didn't count. Another person asked a similar question and neither of
us got a reply.
Peter
1 - 100 of 670 matches
Mail list logo
