Re: [PHP-DEV] [RFC] [Vote] Type Guards for Classes

On Thu, 16 May 2024 at 22:33, Patrik Václavek wrote: > Introduction > * > > This RFC proposes a new feature in PHP: type guards for classes (or > interfaces). This feature aims to simplify and standardize the process of > verifying that a variable is an instance of a specific class,

Re: [PHP-DEV] Two new functions array_first() and array_last()

On Wed, 18 Oct 2023 at 17:47, Levi Morrison wrote: > > I don't see how `array_is_list` is relevant to `array_first` and > `array_last`. PHP arrays are ordered: > > $foo = [ > "first" => 1, > "third" => 3, > ]; > > It would be perfectly fine to use `array_first` or

Re: [PHP-DEV] Two new functions array_first() and array_last()

On Wed, 18 Oct 2023 at 17:05, Robert Landers wrote: > > This is simply not true, 0 is not always the first key in a list, > especially after filtering it. Hence there is a need for this function > in the first place. Just to clarify this point: If 0 is not the first key, then it's not a list.

Re: [PHP-DEV] Previous discussions about generics syntax only?

Hi, yes there was, back in 2020: https://externals.io/message/111875 - Benjamin On Mon, 16 Oct 2023 at 16:08, Olle Härstedt wrote: > Hello internals, > > Was there a previous discussion about the pros/cons of adding only the > syntax needed for generics, but not the functionality? So static >

Re: [PHP-DEV] Reflection*::hasAttribute()

> > I think that would require an RFC. > > To clarify, you're proposing to replace this: > > count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == > true > > with > > (new ReflectionClass(Beep::class))->hasAttribute(Ignore::class) > > Right? That doesn't seem like a huge

Re: [PHP-DEV] Possible RFC: PDOStatement::addBatch

On Wed, 14 Jun 2023 at 01:41, Vinicius Dias wrote: > Hello, folks. I hope you all are well. > > I was talking to friend about a feature I would like to see in PHP but > I mentioned that unfortunately I do not have the knowledge to try > implementing it myself, since it is not something very

Re: [PHP-DEV] Proposal: native decimal scalar type support

Le mer. 26 avr. 2023 à 12:29, Alexander Pravdin a écrit : > As a user, I want to have native decimal scalar type support. > For what it’s worth, this is already solved in userland: https://github.com/brick/math Now having always-available support for arbitrary precision math in the language,

Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2

> > > That's a intentional behaviour change and related to this accepted PHP > 8.2 RFC: https://wiki.php.net/rfc/iterator_xyz_accept_array > > > > Smile, > > Juliette > > It is rather related the following RFC: > > https://wiki.php.net/rfc/dnf_types > > The change was discussed in this thread: > >

[PHP-DEV] ReflectionType for iterable / PHP 8.2

Hi internals, It just came to my attention that there is a change of behaviour between PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into Traversable|array when reflected: ``` function foo(): iterable {} function bar(): stdClass|iterable {} echo (new

Re: [PHP-DEV] DB specific PDO subclasses questions.

On Mon, 6 Jun 2022 at 21:15, Dan Ackroyd wrote: 2. Other than the SQLite blobOpen functionality, does anyone know of > any other functionality that is exposed by SQLite or Postgres that > isn't currently exposed through the magic PDO methods? > Hi, what about the ability to load an extension on

Re: [PHP-DEV] Re: Array comparison works completely different than documented?

> > The point is that $a > $b is actually checking whether $b <= $a. This > is fine for ordered values, but these arrays are not orderable > (according to PHP's comparison). That might indeed not be documented in > the PHP manual (the language specification appears to be abandoned anyway).

Re: [PHP-DEV] Change of $depth behaviour in json_encode() on PHP 8.1

> > > This is a bug. Please report it on https://bugs.php.net/ > > See https://3v4l.org/vFgh0 > > https://github.com/php/php-src/commit/f9f8c1c79cac1b03279190e0c5513a51881615f9 > https://github.com/php/php-src/pull/6811 > > Best Regards, > Kamil > Thank you! Reported as

[PHP-DEV] Change of $depth behaviour in json_encode() on PHP 8.1

Hi internals, I noticed a change of behaviour on PHP 8.1: https://3v4l.org/DoG4A ``` // depth 1 $a = new \stdClass(); // depth 2 $b = new \stdClass(); $b->x = $a; // depth 3 $c = new \stdClass(); $c->x = [$a]; var_export(json_encode($a, 0, 0)); echo "\n"; var_export(json_encode($b, 0, 1));

Re: [PHP-DEV] Order of properties in (array) cast on PHP 8.1

> > Yes, this change is expected and documented, see: > > https://www.php.net/manual/en/migration81.other-changes.php#migration81.other-changes.functions.core > Thanks for the pointer! And sorry for the noise. — Benjamin

[PHP-DEV] Order of properties in (array) cast on PHP 8.1

Hi internals, While running the test suite of one of my libs against PHP 8.1, I noticed that the order in which properties are returned in an (array) cast has changed. For example when casting an instance of this class to array: class A { private $x = 'x'; } class B extends A { public

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

> > >Before doing so, shouldn't we discuss whether it makes sense to accept > >a > >time-zone offset with seconds, when the granularity seems to be 15 > >mins? > > > >https://en.wikipedia.org/wiki/List_of_UTC_time_offsets > > > >— Benjamin > > No need. Early timezone offsets in the timezone

Re: [PHP-DEV] Alias stdClass to DynamicObject?

Hi Nikita, Rowan, In the thread for deprecation of dynamic properties, Rowan suggested that > we alias "stdClass" to "DynamicObject" in > https://externals.io/message/115800#115802. I wanted to split this > discussion off into a separate thread, as this can be decided > independently. > > The

Re: [PHP-DEV] Request for karma to vote on RFCs

> > I know I’m not a “project leader” for any of the handful large PHP > projects. I also know that I am far from the “top 1000 best developers” > list. But I know that there are not many people (if any) that have a larger > impact of user-land PHP right now. > > (I do acknowledge that there are

Re: [PHP-DEV] [RFC] [VOTE] is_literal

> > There's some BC-breaks to be aware of when switching emulated prepares. > One example I know of is that when using emulated prepares you can reuse > the same placeholder (as in the following example), but with emulated > prepares disabled this does not work. > > $sql = "SELECT * FROM table

Re: [PHP-DEV] Type casting syntax

> I've been thinking about extending PHP's cast syntax to user-defined types, > e.g. not only (int)$foo but also (MyClass)$foo. Currently, a T_STRING in > parentheses is always treated as a constant - would it be acceptable to > hijack this syntax when used in unary operation context, i.e. "("

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote: > On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote: > > > >The name "is_trusted" is misleading. > >Literal is nothing but literal. > > I agree with this. The name is_trusted is going to be the same naming > mistake as "safe mode" was.

Re: [PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

> > I can't think of why this couldn't work. Duke a bug report please at > bugs.php.net? Before doing so, shouldn't we discuss whether it makes sense to accept a time-zone offset with seconds, when the granularity seems to be 15 mins? https://en.wikipedia.org/wiki/List_of_UTC_time_offsets —

[PHP-DEV] DateTimeZone silently falls back to UTC when providing seconds

Hi internals, An issue was brought up on my date-time library, that boils down to the fact that DateTimeZone silently falls back to UTC when providing an offset with seconds: (new DatetimeZone('+01:45:30'))->getName(); // 00:00

Re: [PHP-DEV] Allow commit() without transaction?

> > > I think it is really nice that commit() throws for inactive > transactions. Code paths that mess up your transactions will not go > unnoticed that easily. > +1. I've always found this behaviour in MySQL very surprising and error prone (BEGIN; BEGIN; COMMIT; COMMIT; => no errors), and I'm

[PHP-DEV] Required parameter after optional one

Hi internals, I'm wondering why PHP 8 started warning about required parameters declared after optional ones, when this version is the one that also introduced named parameters, which can take advantage of this: ``` function test($a = 1, $b) { echo $a, $b; } test(b: 2); ``` > Deprecated:

[PHP-DEV] Re: Changes to Git commit workflow

> > Hi everyone, > > Yesterday (2021-03-28) two malicious commits were pushed to the php-src > repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how > exactly this happened, but everything points towards a compromise of the > git.php.net server (rather than a compromise of an

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

On Sun, 21 Mar 2021 at 15:18, Rowan Tommins wrote: > I can see three ways forward: > > A) Raise a deprecation notice in 8.1, and remove in 9.0. Do not provide > a specific replacement, but recommend people look at iconv() or > mb_convert_encoding(). There is precedent for this, such as >

Re: [PHP-DEV] PDO::PARAM_INT and pgsql driver

> >> Is there any reason why the pgsql driver doesn't respect PDO::PARAM_STR? > > > > Looks like a bug to me. I thought this had been fixed a while back, but > > apparently it wasn't. I'll try to find some time to investigate in the > > next few days. > > Looks like the problem is in > < >

[PHP-DEV] PDO::PARAM_INT and pgsql driver

Hi internals, I just stumbled upon what I consider to be a bug with the PDO pgsql driver. *TL;DR: the driver treats parameters bound with PARAM_INT the same as PARAM_STR.* Take the following example: ``` $pdo = new PDO('pgsql:host=localhost;port=5432', 'postgres', 'postgres'); $statement =

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

> > Maybe off-topic, but I don't think you could "fix" them: > for array_map, the array is variadic-like, so must be last; > for array_filter, the callback is optional, so must be after the array. > (Correct me if I'm wrong.) > > -- > Guilliam Xavier > Good point. Then that would be an

Re: [PHP-DEV] [RFC] Namespaced in bundled extensions

Thank you for this RFC, Nikita. This is a necessary first step in the right direction. Even though this is out of scope for this RFC, I hope that moving standard functions to namespaces will be an opportunity to fix inconsistencies in parameter order, like: array_map($callback, array)

Re: [PHP-DEV] Re: [VOTE] Enumerations

Congratulations  and thank you Larry and Ilija, this will be a great addition to PHP! — Benjamin On Wed, 17 Feb 2021 at 15:31, Larry Garfield wrote: > On Wed, Feb 3, 2021, at 11:28 AM, Larry Garfield wrote: > > The vote on the Enumerations RFC is hereby opened. It will run until > > 17

Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

On Sat, 6 Feb 2021 at 00:46, David Gebler wrote: > Generating a warning on explicit casts of (non-integer) floats to int > would IMO make no sense at all, it would put PHP at odds with other major > languages such as C, Python and Java and go against normal, reasonable > expectations of how a

Re: [PHP-DEV] Inheritance Cache

On Fri, 5 Feb 2021 at 15:03, Dmitry Stogov wrote: > Hi, > > I'm glad to present the result of my recent work - Inheritance Cache. > > https://github.com/php/php-src/pull/6627 > > This is a new transparent technology that eliminates overhead of PHP class > inheritance. > > PHP classes are

Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

On Fri, 5 Feb 2021 at 11:56, AllenJB wrote: > (And after checking the manual, I'd also note here that round() also > returns a float, so how exactly does your example here work? Is it only > OK to explictly cast a float that's the return value of a function? Or > only explictly cast a float if

Re: [PHP-DEV] [RFC] Warning for implicit float to int conversions

On Thu, 4 Feb 2021 at 17:05, G. P. B. wrote: > Greetings internal, > > I'm proposing a new RFC which would warn when an implicit conversion > from float to int occurs. > > The draft is currently located on GitHub: > https://github.com/Girgias/float-int-warning/ > for ease of commenting/providing

Re: [PHP-DEV] password_verify() and unknown algos

Hi all, thanks for the constructive feedback. On Fri, 29 Jan 2021 at 15:52, Marco Pivetta wrote: > > Gonna be the usual person saying: let's not clutter functions with more > behavior than what's needed :-) > > If you need to validate a hash for being "well formed" rather than > "matching",

[PHP-DEV] password_verify() and unknown algos

Hi internals, I just spent some time debugging an authentication issue after upgrading PHP, and realized that it was due to ext-sodium not being installed, so password_verify() would always return false for argon2i hashes. Digging a bit more, I realized that password_verify() does not complain

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

> > Moreover, I'd rather we get rid of the warning modes all together as they > make the least sense to me. > Either you're handling the failures explicitly anyway and you use the > silent mode, or you don't and want it to throw with the exception mode. > The warning mode is literally the worst of

Re: [PHP-DEV] Proposal: short_var_export($value, bool $return=false, int $flags=0)

> Hi Tyson, > > The formatting of var_export is certainly a recurring complaint, and > previous discussions were not particularly open to changing current > var_export behavior, so adding a new function seems to be the way to > address the issue (the alternative would be to add a flag to

Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays

> I probably brought this up in a previous thread, but I think it's worth > considering again here, given recent changes to the RFC: > > I think it would make more sense to introduce this as `function > array_is_list(array $array): bool`. That is, a function that only accepts > arrays in the

Re: [PHP-DEV] [RFC] Enumerations, Round 2

> > What's the quickest way (=less code) to have an enum represent it's > lexical name as the literal values? > > So that `… case Foo; case Bar; …` results in `::Foo->value === 'Foo'` etc.? > > Is this possible without implementing this manually for all cases? > > AFAICS, you'd need to implement

Re: [PHP-DEV] Proposal: Adding SplFixedArray->push() and SplFixedArray->pop()

On Tue, 29 Dec 2020 at 18:04, tyson andre wrote: > Hi Internals, > > Currently, PHP doesn't have a built in memory-efficient array type with > convenient push, pop, and other operations, similar to a list/vector in > other languages. > The closest built in in SPL is [SplFixedArray]( >

Re: [PHP-DEV] [RFC] Enumerations, Round 2

Hi Larry, thank you for the updated RFC! I love it, and having played with the implementation, I can say I love it so far as well. I have one suggestion regarding reflection: Shouldn't ReflectionCase expose an additional getInstance() method, that would return the case instance, such as

Re: [PHP-DEV] [RFC] Enumerations

On Wed, 9 Dec 2020 at 19:48, Mike Schinkel wrote: 5. Someone else mentioned shortcut syntax, which I would like to mention > again, although I realize implement details might make this a non-starter. > > So if I have a function that accepts a Size from above, e.g.: > > function show(Size $size)

Re: [PHP-DEV] [RFC] Enumerations

Thanks a lot for this RFC, Larry and Iliya! I can't imagine the amount of thought and work put into this. Enums are definitely a most-wanted PHP feature. I played a bit with the early implementation, and love it so far. Here are my thoughts on the RFC and the current implementation:

Re: [PHP-DEV] erorr_reporting() and @ operator

Thanks for the pointer, Nikita. I think the updated example (using `error_reporting() & $errno`) fails to mimic exactly what `error_reporting() === 0` did, though. Say your php.ini mutes E_WARNING, for example: error_reporting = E_ALL & ~E_WARNING Checking for `error_reporting() === 0`

[PHP-DEV] erorr_reporting() and @ operator

Hi internals, Since PHP 8.0, `error_reporting()` started returning a non-zero value when the @ silence operator is used. Demo: https://3v4l.org/CovYv Is this intentional? This breaks scripts that converted all errors to exceptions, except those where the silence operator was used:

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

> Furthermore, Christoph's code uses str_contains() which is only > available in PHP 8 so it's not a good workaround if PHP 7 and 8 must be > both supported. > Here: https://3v4l.org/LHcmN

Re: [PHP-DEV] Thank you to JetBrains (PHP 8 Announcement page)

On Fri, 27 Nov 2020 at 17:44, G. P. B. wrote: > PRs are always welcome on https://github.com/php/web-php :) > > PS: Please try to remember to bottom post and not top post. > Thanks for the pointer! Submitted as https://github.com/php/web-php/pull/364 And sorry for the top-post, I happen to

Re: [PHP-DEV] Thank you to JetBrains (PHP 8 Announcement page)

I really like this page as well! It will definitely help improve PHP's reputation and adoption. I'd like to suggest a couple improvements, though: 1/ Match expression: The new match is similar to switch and has the following features: > (...) > *+ Match throws an UnhandledMatchError if no match

Re: [PHP-DEV] Why there is no StreamWrapper interface ?

On Thu, 12 Nov 2020 at 19:28, Sara Golemon wrote: > Honestly, I kind of regard the state of PHP's filesystem libraries to be > one big hot mess. I'd really much rather redesign them from the ground up > with some BC shims to avoid breaking the world, but I lack the drive to > make that happen

Re: [PHP-DEV] Nullsafe

On Tue, 3 Nov 2020 at 17:38, Eugene Sidelnyk wrote: > I am wondering why don't we use ordinary `->` operator with safe null > handling? Hi, - changing the current behaviour of `->` would be a huge BC break - and if we need another reason, there are many situations where you do want to fail

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

On Fri, 30 Oct 2020 at 19:07, Rowan Tommins wrote: > Just to be clear, the major gain here is not replacing the 10 characters > "function()" with the 7 characters "fn() =>", it is eliminating the list > of captured variables. So you would get equally clean code with a > "capture all" syntax,

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

On Tue, 6 Oct 2020 at 14:09, G. P. B. wrote: > And once *again* short-closure don't *just* have the auto-import of the > outer scope going for it. > The other main features of the short closure are not applicable to a block > syntax. > - the fact that there is an implicit return > - it is a

Re: [PHP-DEV] List of attributes

On Fri, 23 Oct 2020 at 19:08, Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: > We can deprecate comments with "#" in 8.0 or 8.1 > > ... > > Is there anything against excl. BC break of "#" comments? Who is for it? > > I'm all for it, especially considering that it's trivial to fix old

Re: [PHP-DEV] PHP 8 release announcement page on php.net

I can handle the French one if you need someone. Just send me the texts! — Benjamin On Mon, 19 Oct 2020 at 15:59, Sergey Panteleev wrote: > Hi there! > > I'm also ready to help with Russian translation > > wbr, > Sergey Panteleev > On 19 Oct 2020, 16:54 +0300, Roman Pronskiy , > wrote: > > > >

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

> > If you want to make an RFC about it, it really needs a compelling "pros" > section, because there aren't any, so far :-\ I don't agree. There is one pro, and not a small one IMO if you use closures a lot: skip use(). Since arrow functions have been introduced, I've several times naturally

Re: [PHP-DEV] Re: Attributes and constructor property promotion

On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas wrote: > I assume the 80% case is properties, because attributes did not have >> docblock annotations yet, that means this use-case isn't even possible at >> the moment. Yet annotations on properties are widespread (Doctrine ORM, >> symfony validator,

Re: [PHP-DEV] Re: Attributes and constructor property promotion

On Mon, 28 Sep 2020 at 13:56, Benjamin Eberlei wrote: > imho, we should pick the 80% use-case and advise to desugar the code if > other behavior is desired. For me the 80% case is that the attribute only > applies to the property, not to the parameter. +1 for the desugaring advice in this

Re: [PHP-DEV] Attributes and strict types

I'd expect it to obey the strict_types declaration of UseOfMyAttribute.php, too. I see it as being where the attribute's constructor is "called", even though the actual object instantiation happens somewhere else. — Benjamin On Tue, 22 Sep 2020 at 16:11, Larry Garfield wrote: > On Tue, Sep 22,

Re: [PHP-DEV] Community vote on RFCs

> > You're asking for useless, no-effort feedback in the form of votes > from people who have no actual involvement in the ongoing development > or maintenance of the project, so that's what I gave you. I'm surprised by these strong feelings. As a contributor and maintainer of several open

Re: [PHP-DEV] Community vote on RFCs

Thank you for your feedback, Ben & Stanislav. *Ben:* It’s all fairly transparent, and if non-voting members want to provide > input, they have various ways to do so (e.g., posting here, giving > feedback to someone who is active here, etc.). While this is true, I'm afraid the opportunities to

[PHP-DEV] Community vote on RFCs

Hi internals, The heated debate about attribute syntax made me think once again that it would be valuable to get feedback in the form of votes from the community, not just from core developers, on RFCs under discussion. Understandably, the RFC voting process needs to be restricted to carefully

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Tue, 18 Aug 2020 at 08:49, Aleksander Machniak wrote: > > I wonder why my suggestion (somewhere in this thread) didn't get any > attention. Is it because the ship had sailed or it's a terrible idea? > > declare( > SomeAttr, > AnotherAttr("Hello world") > ) > function someFunc() { > }

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

> > I am for stopping the current voting too - because the results are very > different vs. the previous voting, they are almost random and the > discussion is still very hot which violates rule when voting can be > started. For what it's worth, I'm for resetting the voting, too, and restart it

Re: [PHP-DEV] [VOTE] Saner string to number comparison

Thanks for this RFC, Nikita! This is definitely a step in the right direction, and I can only hope it will pass. One question: > (...) by using a number comparison only if the string is actually numeric. > Otherwise the number is converted into a string, and a string comparison is >

Re: [PHP-DEV] Re: [RFC] [VOTE] Locale-independent float to string cast

Thank you Mate, this will be a very welcome change, that will naturally fix bugs such as this one , and probably others going unnoticed. Benjamin On Thu, 7 May 2020 at 14:02, Máté Kocsis wrote: > Hi Internals, > > I'm pleased to announce that the

Re: [PHP-DEV] Moving json extension to core?

> > Looking at Ubuntu 20.04, they seem to > have json built-in to the core package anyway. I'm not sure about other > distros. Fedora packages it separately as php-json. I'm a big +1 on moving this extension to core. I've actually asked 2 weeks ago if it could be disabled

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

> VAR_EXPORT_NO_INDEX Note that I wouldn't consider a BC break to change var_export()'s behaviour to always discard indexes when they're numeric, I'm not sure this should even be an option! - Ben

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

> > If "they" don't care about syntax, then why do you? Sorry I was unclear. I was reacting to the argument about broken tests in php-src. I meant: they don't have *expectations* about the syntax, but they'll most likely want to be able to read it. — Benjamin

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

> > "Then why not use brick/varexporter?" As much as I'm pleased that people use this library, I consider it a shim, waiting for PHP to ultimately provide the same functionality. See the (object) cast for stdClass, that was supported by varexporter but was later added to var_export(). I don't

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax to use short hand arrays

+1 for this. This is the syntax I'm using in brick/varexporter , and supporting it natively in var_export() makes sense. — Benjamin

Re: [PHP-DEV] Class cast

> > Currently PHP supports generic castings like (string), (int), ... maybe is > time to allow class castings like (ToClass) $fromObject? I've proposed something similar a year ago: https://externals.io/message/105332 My intention wasn't to create an object from a scalar, nor was it to limit to

Re: [PHP-DEV] Proposal for a new basic function: str_contains

> > Thanks for the karma! An RFC has been created: > https://wiki.php.net/rfc/str_contains Something that's missing from the RFC is the behaviour when $needle is an empty string: str_contains('abc', ''); str_contains('', ''); Will these always return false? — Benjamin

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> > What about $query and $body? That would be closer to the terminology > used in HTTP RFCs. The problem is that $body is typically used to get the raw message body as a string or stream. I was thinking more something along the lines of $bodyParams, which is more verbose but leaves no

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> > Having said that, we are willing to revisit that naming decision if > there's support for doing so. Perhaps: > - rename $get to $query, populating it from `$globals['_GET']`, on the > basis stated above > - rename $post to $input, populating it from `$globals['_POST']`, on the > basis that it

Re: [PHP-DEV] Moving the documentation to git

> > So the main question is now, how the PHP-Project wants to go on with > moving the documentation from SVN to git? Is there any interest in > continuing this project? Yes please. I would contribute a thousand times more if I could just make PRs on GitHub. Right now I'm being put off by the

Re: [PHP-DEV] Operator overloading for userspace objects

I like this whole operator overloading thing. I would probably use it in brick/math and brick/money to replace verbose `->plus()`, `->multipliedBy()` etc. calls. > Can you only compare 2 of the same type? What about subclasses?

Re: [PHP-DEV] How to debug a segmentation fault?

> > Infinite recursion leading to a segfault is **a known bug with no plans to > be fixed that I know of,** which I've encountered many times. That's unfortunate; as I said in the bug report, it's so easy to trigger and so easy to miss when reviewing the code! And the process crashing instead of

Re: [PHP-DEV] How to debug a segmentation fault?

Jan 2020 at 18:19, Bishop Bettini wrote: > On Tue, Jan 28, 2020 at 11:28 AM Benjamin Morel > wrote: > >> I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The >> bug seems to happen during the rendering of a Twig template; this makes it >> hard for me to

[PHP-DEV] How to debug a segmentation fault?

Hi internals, I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The bug seems to happen during the rendering of a Twig template; this makes it hard for me to pinpoint the code that triggers the segfault. Could you please tell me what the procedure to collect information is, so

Re: [PHP-DEV] The future of SQLite3 and PDO/SQLite extensions

> > I think that PDO_SQLite should get the same features as the SQLite3 > extension, and the SQLite3 extension should be deprecated and > eventually removed and replaced by a userland library that would wrap > around the PDO_SQLite API. Hi BohwaZ, Having only PDO_SQLite sounds good to me.

Re: [PHP-DEV] Typed array properties V2

> > What if we left the array type alone, and instead focussed on "list" > type and "dict", "dict" types? > That would allow a clear break from previous behaviour, and would allow you > to introduce other changes (e.g. removing string -> int coercion for > numeric string keys). Can't agree

[PHP-DEV] Union types | true pseudo-type

Hi internals, I'd like to bring back the topic of supporting "true" as a type in PHP 8 union types. Now that the RFC has been successfully voted, I'd like to revive the discussion about adding the "true" pseudo-type in addition to "false". In addition to

[PHP-DEV] WeakMap vs PECL WeakMap

Hi Internals, A year ago, when WeakRef was being proposed, some objections related to the PECL Weakref package had lead the RFC author, Joe Watkins, to rename WeakRef to WeakReference to avoid conflicts.

Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas

I've been actually surprised by the rejection myself, especially considering that @ocramius, whose profile seems similar to Nicolas', already has a seat. Don't get me wrong, I have a lot of respect for @ocramius and all of his work on PHP open-source projects, but he doesn't seem to have

Re: [PHP-DEV] [RFC] Static return type

> > I would like to propose the following RFC, which allows using "static" as a > return type: > https://wiki.php.net/rfc/static_return_type Big +1 from me as well. I actually asked why this wasn't supported back in 2015: static return type in PHP 7 interfaces

Re: [PHP-DEV] Support for Async / Await

> > Does this actually fit in with php's execution model of each request > being a separate thread / process? I can see this being useful, when AJAX-querying an endpoint that has to do, in turn, 2 or more API calls or other async jobs to build its response. (although async HTTP requests are

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

> > One interesting thing with item #1 is that it allows for remote arbitrary > code execution even if no include-able path on a server is writable. This > comes into play if there's a supply chain attack on your app. Say, an > infected update on a CMS plugin. Get an eval() of a

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Hi Ian, IMO, eval() is secure, as long as: - you’re not using it, or - you’re using it properly I’d say that as soon as your server has been compromised, eval() is the last of your worries, as pretty much anything becomes possible, including writing PHP code to a file and including/executing

Re: [PHP-DEV] [RFC] Add WeakMap

Hi Nikita, After reading the RFC, I have no comments to make, but I just want to thank you for working on this. I regretted a lot that this wasn't implemented together with WeakReference in PHP 7.4 , as the use cases for WeakReference vs WeakMap are really

Re: [PHP-DEV] Optional pre-compiler for PHP8?

> > This would break as soon as we have two versions of a class, and a > runtime choice which of them to use. > (see also Mark Randall's comment) That's why I'm suggesting to only make these optimizations when preloading is in use, which means that you know

Re: [PHP-DEV] Optional pre-compiler for PHP8?

> > > So we'd probably need some built-in definition of a "package", which > could be analysed and compiled as one unit, and didn't rely on any run-time > loading. > That idea of a "package" came up during a debate on this list at least > once, a few months ago, and I think it makes a lot of

Re: [PHP-DEV] Re: [RFC] Union Types v2

> > As they are runtime checks, would an ini setting where they can be > completely disabled be feasible? So during development and in production > when the performance decrease doesn't matter, I can have the full runtime > type checking. But when absolutely needed, the checking can be disabled.

Re: [PHP-DEV] Re: [RFC] Union Types v2

> > I think this performance impact is a real concern; PHP is the only language > I know of which implements type checks entirely at run-time in production > code, and we should ask ourselves if that's definitely the right approach. Would it be possible, at least in principle, to build a static

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

sal, even if I can hardly imagine it overcome the usual resistance here. This proposal would be as good under the form of a new API though, but in this case the naming should be changed to clearly differentiate both APIs. I wish you luck, @David, anyway. — Benjamin On Mon, 21 Oct 2019 at 23:59, R

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

ors, that you get almost for free with exceptions and a single try/catch at the top level. — Benjamin On Mon, 21 Oct 2019 at 20:46, Rowan Tommins wrote: > On 21/10/2019 18:45, Benjamin Morel wrote: > > I personally like exceptions in all cases, as they allow for > > fine-grained e

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

> I agree with the distinction described by Nikita. > There are definitely cases where a special return value is still the > best option. I personally like exceptions in all cases, as they allow for fine-grained error handling, for example: ``` try { mkdir('somedir'); } catch

Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions

> I'm considering writing an RFC (and a patch) to turn some warning into > exceptions in a number of PHP functions. > I would first like to gather some feedback here. I would *LOVE* if these functions could be fixed, and if I had the almighty merge button at my disposal, I'd press it whenever

  1   2   3   >