ple `rollbackToSavepoint(string $name)`.
Regards.
Kentaro
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
warnings being converted to exceptions by error handler is
equivalent to checking return value with regards to the set of error
conditions covered? If this guarantee is already there, please point to
me to the relevant documentation page.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> On Dec 9, 2023, at 4:55 PM, Robert Landers wrote:
>
> On Sat, Dec 9, 2023 at 4:32 PM Dennis Snell via internals
> wrote:
>>
>> Max, I love this idea.
>>
>> Would it make sense to flip the design though and add `#[Serializable]` with
>> a
ase let me know what you think.
>
> --
> Best regards,
> Max Semenik
>
> --00006c4879060c12de83--
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
check_encoding() before operating on
> them. Unfortunately, "should" doesn't count for much. Most users will not do
> what they "should".
>
> 5) Amending the documentation to call out these dangers more clearly would be
> a positive step, though probably not enou
vely pressed on.
>
> The story ends with an ironic twist. Many years later, I became interested in
> mbstring and reimplemented its internals, replacing the libmbfl code with
> fresh new code which ran many times faster. The new code was so much faster
> that in some cases, the mb
MAY
do nothing (or SHOULD NOT do anything).
Regarts.
Kentaro Takeda
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
.php.net/manual/en/function.mb-strpos.php
[2]: https://www.php.net/manual/de/function.mb-substr.php
[3]: https://www.php.net/manual/de/function.mb-strstr.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> The migration path is to convert the legacy-encoding PHP files to UTF-8.
Please take a look at the following code.
This is a part of the code that I am actually maintaining in the
latest version of php.
```php
https://www.php.net/unsub.php
On Tue, Nov 7, 2023 at 11:46 AM Sebastian Bergmann wrote:
> Am 07.11.2023 um 11:33 schrieb Thomas Chauchefoin via internals:
> > For instance, the official Docker image has it on [2].
>
> "Official" is relative here. That image is maintained by (the) Docker
> (comm
://hub.docker.com/_/php
[3]: https://www.youtube.com/watch?v=yq2rq50IMSQ
[4]: https://github.com/advisories/GHSA-jm6m-4632-36hf
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
1 = true ; -- `ERROR: operator does not exist: integer = boolean`
The conditions for casting and comparison were different.
`PDO_PARAM_INT` still needs to be passed as `unknown` to PostgreSQL.
Thank you!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://ww
ributions are interesting and invaluable. They
are much appreciated.
Best regards
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
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
I consider the current behavior a bug.
And some of them contain behaviors that are very confusing to users.
gly) leave empty() and warn against its use, and have
is_empty() as a new thing. Maybe for some future deprecation or
removal?
I also do like the idea that someone else mentioned here about being
able to possibly start to get away from @'ing variables with a
solution like this.
-B.
--
PHP Inter
fine to use `array_first` or `array_last` with
`$foo`. I think probably you would use `array_key_first` and
`array_key_last` so you also get the key and not just the value, but I
don't see any need to reduce `array_first` and `array_last` to only be
logical or correct with arrays that uphold `arra
t($array);
if ($value === null) {
// handle the failure
} else {
// success
}
```
But I fear in practice people will just omit the error checking.
One way around that is to throw an exception. I'm not sure how I feel
about that, but I'll think about it.
--
PHP Internals - PHP Runtime Developme
On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov wrote:
>
> Hi internals,
>
> The vote on "A new JIT implementation based on IR Framework" RFC is started.
>
> https://wiki.php.net/rfc/jit-ir
>
> Thanks. Dmitry.
>From the RFC:
> The details of the IR fram
> Just chiming in here to say that while we don't offer a createFragment() in
> this proposal, it's possible to parse fragments by passing the
> LIBXML_HTML_NOIMPLIED option. Alternatively, in the future I plan to offer
> innerHTML which you could use then in conjunction with
>
appropriate, that they aren’t supplying HTML
documents with in-band text encoding information, and so there’s a chance that
de-emphasizing the parameter may be technically more accurate and practically
less helpful.
Love seeing all the continued work on this!
Thank you so much for your dedicat
is recommendation. Perhaps someone has time to investigate
this? Anyway, it's "future work."
I have voted for 11, but will not be hurt in any way if 12 wins.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
eferences.
Kindly,
Dennis Snell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Den 2023-09-11 kl. 11:28, skrev Dmitry Stogov:
Hi internals,
I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.
It makes a base for future
ote:
>>>
>>> I'm opening the discussion for my RFC "DOM HTML5 parsing and serialization
>>> support".
>>> https://wiki.php.net/rfc/domdocument_html5_parser
>>> <https://wiki.php.net/rfc/domdocument_html5_parser>
>>>
>>> Kind regards
>>> Niels
>
Impressive proposal. It will be nice to have. Did you consider any tricks for
text encoding, such as converting non-utf8 documents into utf8 first before
parsing? Was wondering if we did that if we could lean on `iconv` and save the
extra data in the library, if that’s important enough.
Cheers,
Dennis Snell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Thanks for the proposal Niels,
I’ve dealt with my own grief working through issues in DOMDocument and wanting
it to work but finding it inadequate.
> HTML5
This would be a great starting point; I would love it if we took the
opportunity to fix named character reference decoding, as PHP has
ture. It
> will be unexpected for users if their code completely fails to work on
> Windows, because the suffix is ignored.
>
> For that reason I voted "no".
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To
atting - obviously the totally other side - the current default is
surprising, too.
But it is certainly the safer path to not change it.
For now, I've already learned a lot more and should take some time to
look into this. E.g. understanding why this is the default in ICU,
perhaps there is
On Thursday 03 August 2023 21:07:35 (+02:00), Tim Düsterhus wrote:
> Hi
>
> On 8/3/23 20:55, Hans Krentel via internals wrote:
> > Feedback from actual ICU caretakers would be good though, because me
> > is entirely from a users perspective, also I know how to change
attributes to non default values, this is not a programming question
I have.
I hope you don't mind the attention to detail.
Best
-- hakre
[1]:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat#roundingmode
--
PHP Internals - PHP Runtime
the
discussion and the voting.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
, create new or would it be better to start with a RFC?
Links:
[1] https://github.com/php/php-src/pull/950
[2] https://linux.die.net/man/3/freopen
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
s everyone has gone through.
>
> In short, I suspect at least much of the pushback is "that is weird and not
> normal, according to the normal I first learned, so it must be a bad idea,"
> and people just stop there.
>
> (If you voted no and the above description doesn't apply to you, please do
> explain what your alternate reasoning is, because RFC authors desperately
> need more feedback than we get right now.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
n. This is probably going to bite in the longer term.
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
I suppose different people will think different thing
On Wed, Jun 28, 2023 at 10:09 AM G. P. B. wrote:
>
> Hello internals,
>
> I'm opening the vote for the
> Deprecate remains of string evaluated code assertions RFC:
> https://wiki.php.net/rfc/assert-string-eval-cleanup
>
> It will last for two weeks and end on Wednesday t
led 'default cancelling':
```php
interface Interface1 { function m1() { /* ... */ } }
interface Interface2 extends Interface1 {
function m1(); // may or may not change signature
}
```
For various reasons which I'll put in the RFC, this will "cancel" the
default, meaning any class which implements Interface2 instead of
Interface1 will not receive that default.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
code. It is
code that has been working flawlessly for 9 years, so it's only work and
no benefit. Given that deprecations are piling up for 8.x track I think
one should be a bit cautious when approaching the next major version.
r//Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
Good morning, all!
This is a friendly reminder from your RMs that the PHP 8.3 feature
freeze is in ~4 weeks on July 18th [1]. Alpha1 is already out and Alpha2
is scheduled this Thursday.
All new features and RFCs need to be discussed with voting polls closed
on or before July 18th for
On Sat, Jun 17, 2023 at 4:10 PM David Gebler wrote:
>
> On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals
> wrote:
>>
>>
>> I am moving my RFC for interface default methods to discussion:
>> https://wiki.php.net/rfc/interface-default-methods.
>
On Fri, Jun 16, 2023 at 11:51 AM Deleu wrote:
>
>
> On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals
> wrote:
>>
>> Hello, PHP Internals,
>>
>> I am moving my RFC for interface default methods to discussion:
>> https://wiki.php.net/rfc
er evidence, I would say to allow it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
have added a brief section in RFC impact that code analysis tools
will need to be updated. This is implicitly true for many language
features, but I see no harm in calling it out in the RFC, so I have
done so. Thank you for the feedback.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
f
> what can happen once the RFC would be accepted.
Juliette, it's in the RFC under the second bullet point here:
https://wiki.php.net/rfc/interface-default-methods#backward_incompatible_changes.
Is there something specific you'd like added there?
--
PHP Internals - PHP Runtime Developme
Hello, PHP Internals,
I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.
This can be a useful tool for a few reasons:
1. It can make implementing an interface easier when certain methods
can be implemented by other methods
t if something is
done, but it's not much of a problem.
The problem is when there's a wildly different signature, or if args
change the return type structure, etc. So in this case, the problem is
really:
public function __construct(string $isostr, int $options = 0) {}
Which can't really be unified with the others very well.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y I managed to create a working implementation for this feature which
> would make it possible to properly modify readonly properties
> while simplifying how we write "wither" methods:
> https://wiki.php.net/rfc/clone_with
>
> Regards,
> Máté Kocsis
I apologize if this has been
k.
>
> Best,
>
> Boro Sitnikovski
>
I'm sorry if one of the many replies already mentioned this, but there
was a failed RFC for `array_group`:
https://wiki.php.net/rfc/array_column_results_grouping. Note that I
voted against it for technical reasons (the signature was just awful,
we can do better), but I am not against the idea of adding such helper
functions in principle.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> karma would need your Wiki name.
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ot, don't create it, as otherwise you have the copy
already and this prevents you from learning if the file transaction really
needs it to become robust or it is just extra I/O for nothing (and perhaps
introduces places to error you actually don't want to deal with).
YMMV.
-- hakre
--
PHP
($tempHandle, "hello world\n");
rewind($tempHandle);
$result = file_put_contents($destinationPath, $tempHandle);
fclose($tempHandle);
Why move the temporary file when it is already a temporary file, right?
-- hakre
--
PHP Internals - PHP Runtime Development Mailing List
To uns
allow `new class() extends $someClass` in
the future to specifically allow them to do this. I mean, I'm not
going to lobby for it, I'm just pointing out that is more aligned and
consistent with other parts of the language, than to simply make it
final by default.
Cheers.
--
PHP Internals - PHP
object) as those are not
supported by ini_get()/in_set().
-- hakre
p.s. thank you for creating this RFC and taking care.
[1]: https://www.php.net/manual/en/function.assert.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
PHP 8.3 release management
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
some bad downsides if "the wrong people" get in there. You know,
the power-hungry egotistical kind of people.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Thu, Apr 20, 2023 at 9:57 PM Deleu wrote:
>
>
>
> On Thu, Apr 20, 2023 at 8:23 PM Levi Morrison via internals
> wrote:
>>
>> I'm going to stop here. Two big things:
>>
>> 1. I think reducing verbosity can be left for the future. We don't
>>
, int $y): int $c */
function takeTwo(callable $c);
takeTwo(fn ($x, $y) => $x + $y);
3. And another reason they failed: callables are going to want
generic types pretty commonly. Think array_filter, array_map, etc.
So, I think these brain dump RFCs are all focusing on the wrong problems.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Den 2023-04-13 kl. 10:38, skrev Mikhail Galanin via internals:
Hello good people,
Looks like another hot discussion on the list, isn't it?
Just wanted to share my notice about the initial idea.
7 years ago there were people considering NNTP as an option. Nowadays,
it's pretty clear
3 at 2:53 PM 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
added value besides completely new features.
E.g. one of my favourites was the Pipe operator RFC.
Regards //Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
areas for
improvement of PHP, e.g. like a roadmap/wishlist for 9.0?
Regards //Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Monday 10 April 2023 14:17:04 (+02:00), G. P. B. wrote:
> Hello Internals,
>
> Dan and I would like to propose a new core autoloading mechanism [...]
>
> The existing SPL autoloading functions would become aliases to the new
Core
> ones and will continue to work with
Original message From: Andreas Leathley
Date: 2023-04-11 07:19 (GMT-08:00) To: internals@lists.php.net Subject: Re:
[PHP-DEV] Future stability of PHP? On 11.04.23 15:56, Jeffrey Dafoe wrote:>> So
turn off the deprecation warnings for now. They're just a he
m a specialization form
then, e.g. ::offsetPush($offset, iteratable $values) which should be
optional, or perhaps even with offsetSet($offset, mixed ...$values) as an
optional upgrade if PHP semantics allow such changes.
Just my 2 cents.
-- hakre
--
PHP Internals - PHP Runtime Development Mail
in userland since 2005 and dabbling in
internals (mostly to understand FFI and interoperability) since 2016.
I'm not a C guru as in I can't reliably _write_ greenfield C code. But I
have worked with and on C/C++ teams and am well adept at groking
existing code, hunting for bugs, and ensuring
recation so that
> > for the upcoming PHP8 releases each call to ldap_connect with 2
> > parameters would emit a deprecation message so that people have enough
> > time to adapt their code before we can actually remove using two
> > parameters in the next major release.
> &
It's just unfortunate it
takes so long, but that's how it goes sometimes :/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ed january 2014 9 years ago,
could it be an option to bring it up again in conjunctione with your RFC?
Maybe the added value of your RFC could swing the opinion. I mean there has
been RFC's that required multiple tries to fly.
Regards //Björn L
--
PHP Internals - PHP Runtime Development Maili
resume this effort.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I'm in support of such a feature, but would strongly advocate for an
additional parameter to flag whether or not to include the trailing `=`
pad. The trailing pad is optional according to RFC 4648, so I think
leaving it off by default would be the ideal use case, but an optional
M Derick Rethans wrote:
>>
>> On Fri, 21 Oct 2022, Mikhail Galanin via internals wrote:
>> > Looking into the future, probably we would like to have this format
>> > configurable, if so it looks easy to do but still I can't see an easy
>> > way to handle the micros
og checking, I often forget that PHP uses a
> different date format... admittedly, it can help having the month spelled
> out, so no one accidentally thinks it's the American format :-)
>
> Craig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
concludes.
Cheers
Joshua Rüsweg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ld have
provided a custom comparator in this case, no "fix" necessary in core.
Of course, this complaining doesn't fix the situation we are in. My
first impression is that might be better to provide one or more
alternative functions and to deprecate `array_unique`.
--
PHP Internals
or single iterable (and ?iterable) to produce
>a ReflectionNamedType with name iterable, however usage of iterable in
>union types will be converted to array|Traversable
[1]: https://github.com/php/php-src/blob/PHP-8.2/UPGRADING
--
PHP Internals - PHP Runtime Development Mailing List
To u
me. `getBytesFromList`
sounds to me as if an array is being passed there and not a string.
`getBytesFromString` sounds good to me, though. Better than
`getBytesfromAlphabet`!
Cheers
Joshua Rüsweg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
the getFloat method with a parameter that
specifies which type of interval should be generated (Open, Closed,
Right Half-Open and Left Half-Open).
Are you happy with the enum names? Have you any other suggestions?
Cheers
Joshua Rüsweg
--
PHP Internals - PHP Runtime Development Mailing List
ng for using
> an array as an optimization.
Oops, I meant to say I think this should return an iterable, not an array.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
re variants, for instance `fold`
and `fold_with_keys` (where we provide both key and value). I
definitely do not like it when we change function signatures of
callbacks based on `flags` parameters like some PHP functions do
today.
Phew, I'm not sure the mailing list is the best way to the tid
r and also no need for them to be
> rechecked by maintainers regularly. Then there's also the issue of
> what's effectively false-positives (see below) which further distract
> from whatever benefit to the automated scan there might be in the first
> place.
>
> On 10/24/22 19:05, P
here, I'm open to updating the patch. Basically, I'm open to
everything, please share your opinions.
Pull-request: https://github.com/php/php-src/pull/9844
On Fri, Oct 21, 2022 at 11:46 AM Rowan Tommins wrote:
>
> On 21 October 2022 08:47:30 BST, Mikhail Galanin via internals
&g
Tyson,
Could you expand on that? It isn't obvious from your comment, and I'm
> curious about this initiative at Google.
>
>
> 1. How many hours a week do you spend working for Google/Alphabet,
> roughly? (e.g., averaged over the last month)
> 2. How many hours a week do you spend working for the
probably be an internals API
for handing out POSIX realtime signal numbers for platforms which
support it. Quoting from the signal man page:
> Unlike standard signals, real-time signals have no predefined
> meanings: the entire set of real-time signals can be used for
> application-defined
.
Anyway, it's a bit off topic, so I'll stop here.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hey Jordan,
The tool is only meant to be informative regarding the project's
supply-chain security posture and gives actionable suggestions on how it
can be improved. However, it doesn't create issues, bug maintainers and
volunteers with notifications/emails, or make any assumptions regarding
and share your thoughts
about this topic (maybe there are
strong objections against such a change)?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I've made this suggestion as issue #9778 (
https://github.com/php/php-src/issues/9778) and PR # 9789 (
https://github.com/php/php-src/pull/9789), but have been invited by
@damianwadley to bring it to the mailing list.
The Scorecards GitHub Action basically keeps an eye on a repo's security
causes confusion if any
functions are introduced after the feature freeze. In the end, however,
I think it is the release manager who decides.
Cheers
Joshua Rüsweg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
parameter? Enum?
We're looking forward to your feedback.
Cheers
Joshua Rüsweg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
php-src/pull/9664
[3] https://github.com/php/php-src/pull/9679
PS: Since this is my first contribution, someone needs to give me karma
to open an RFC. My account name is `josh`.
Cheers
Joshua Rüsweg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.
ink it's necessary. You'd need some way to manage where extension
methods are loaded, how they are found, and without pessimizing
performance of method calls in general just because this feature
exists.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.
On Tue, Jul 5, 2022 at 3:39 PM shinji igarashi wrote:
>
> Hello internals,
>
> I've started the vote for the Constants in Traits RFC:
> https://wiki.php.net/rfc/constants_in_traits
>
> The vote will end on 19. July 2022.
>
> Thanks!
>
> --
> Shinji Igarashi
Den 2022-07-08 kl. 18:29, skrev Jordan LeDoux:
On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi wrote:
Hello internals,
I've started the vote for the Constants in Traits RFC:
https://wiki.php.net/rfc/constants_in_traits
The vote will end on 19. July 2022.
Thanks!
--
Shinji Igarashi
I
Hi internals,
eleven months ago, there was an interesting thread about a karma for voting on
RFCs (https://externals.io/message/115464), which resulted in not providing
this karma to Tobias Nyholm.
But in the latest RFCs (like
https://wiki.php.net/rfc/fetch_property_in_const_expressions
ing a nicer API will have quite a bit more discussion and
disagreement than "exposing" or "porting" libcurl's API.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
anonymous function with use(*) for capturing
everything.
Anyway, hope this passes for PHP 8.2!
Regards //Björn Larsson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
tHost, getPassword, etc should be removed and should
expose `curl_url_get` more directly.
Of course, it should be object based instead of resource based, but that's it.
A nicer API can be built on top of it, but I don't think that's the
role this particular API should play.
--
PHP Internals -
, and avoid silent bugs.
Please take everything I say with an extra pinch of salt.
It has been a long time.
Best regards
Stefan
--
Stefan Marr
School of Computing, University of Kent
https://stefan-marr.de/research/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Fri, Jun 17, 2022 at 9:28 AM G. P. B. wrote:
>
> On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus wrote:
>
> > Hi Internals
> >
> > I've come across a case where it would've been useful if
> > `iterator_to_array()` would accept iterable instead of Traversa
erything.
Even if it's outside the scope of this RFC it could be mentioned in
"What about Anonymous Functions?" or "Future scope".
r//Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I'm not sure I'm a fan of the PR as it stands, but the idea of
encrypting session data - definitely.
When sessions are stored on disk, that data is plainly visible by anyone
(or any process) with read access to that disk. If they're cached
instead in a DB or an in-memory system like
Congratulations Sergei and Pierrick!
Cheers,
Evan
On May 18, 2022, Ben Ramsey wrote:
> > On May 11, 2022, at 09:51, Ben Ramsey wrote:
> >
> > Happy middle of the week, everyone!
> >
> > We’ve had another great turn-out for PHP Release Manager selection
> this year.
> >
> > In the role of
1 - 100 of 798 matches
Mail list logo
