Re: [PHP-DEV] Concept: Lightweight error channels

Hi all, > On May 1, 2025, at 09:29, Levi Morrison wrote: > > On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones wrote: >> >> >> >>> On Apr 27, 2025, at 07:26, Niels Dossche wrote: >>> >>> Regarding performance however, rather than int

Re: [PHP-DEV] Concept: Lightweight error channels

> On Apr 27, 2025, at 07:26, Niels Dossche wrote: > > Regarding performance however, rather than introducing yet another completely > new concept to do almost the same thing, why not try to improve exception > performance instead? > > I just opened a PR that makes instantiating exceptions m

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace & Maté and all, tl;dr: I argue against Ignace's objections to splitting the URI class into two classes (one that retains raw URI values and another that normalizes values as-it-goes). Jump to the very end for a discussion regarding the with() methods (search for the word "asymmetry" h

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On Apr 27, 2025, at 16:47, Máté Kocsis wrote: > > Hi Tim, ... >> So it seems to be safer to use the naming without the `raw` and then in >> the documentation explain what happens with useful examples, just like >> the RFC already does. > > We discussed this off the list, an

Re: [PHP-DEV] DokuWiki password reset failed?

> On Apr 24, 2025, at 04:32, Christoph M. Becker wrote: > > On 24.04.2025 at 03:21, Paul M. Jones wrote: > >> I just reset my `pmjones` password on DokuWiki, but the password it sent is >> not letting me in. Is there something else I need to do? > > Since yo

[PHP-DEV] DokuWiki password reset failed?

Hi all, I just reset my `pmjones` password on DokuWiki, but the password it sent is not letting me in. Is there something else I need to do? Sorry for the hassle, and thanks for your patience. -- pmj

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, A one-off comment about the exceptions: The RFC posits that _Uri\UriException_ extends _Exception_, and _Uri\InvalidUriException_ extends _UriException_. However, pre-existing userland solutions to the URI problem lean more heavily on the native PHP _InvalidArgumentException_,

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On Apr 17, 2025, at 15:58, Tim Düsterhus wrote: > > Hi > > On 4/17/25 22:47, Paul M. Jones wrote: >> As such, the _InvalidUriException_ would better extend from _LogicException_. > > No. There is a de facto policy of “not using SPL exceptions in new co

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace & Maté & all, > On Mar 19, 2025, at 16:18, Ignace Nyamagana Butera > wrote: > > https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php > While implementing the polyfill I am finding easier DX wise to make the > constructor private and use instead named constructors for instant

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On Mar 25, 2025, at 03:45, Máté Kocsis wrote: Regarding Rowbot slowness compared to the RFC: > I can only assume that the excessive usage of objects makes the library much > slower than what's possible > even for a userland library (obviously, an internal C implementation w

Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi all, > On Mar 20, 2025, at 01:31, youkidearitai wrote: > > -- Forwarded message - > From: youkidearitai > Date: 2025年3月20日(木) 14:41 > Subject: Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ? > To: Paul M. Jones > > > 2025年3月19日(水) 2:52 Pau

Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi Rowan & all, > On Mar 22, 2025, at 10:20, Rowan Tommins [IMSoP] wrote: > > On 21/03/2025 11:17, Tim Düsterhus wrote: >> >> I am not sure if that signature makes sense and if the proposed >> functionality fits into mbstring for that reason. IRIs are defined as UTF-8, >> any other encoding r

Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi Tim & all, > On Mar 21, 2025, at 06:22, Tim Düsterhus wrote: > > Am 2025-03-18 18:48, schrieb Paul M. Jones: >> $iriPath = '/heads/' . rawurlencode($val) . '/tails/'); >> assert($iriPath === '/heads/fü bar/tails/'; // false > > Fr

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté, > On Mar 18, 2025, at 15:15, Máté Kocsis wrote: > > There's no way I would have written an implementation from scratch. I'm using > the url module of the Lexbor C library (https://github.com/lexbor/lexbor/) > for handling WHATWG URLs. It's already bundled in core, and it's also batt

[PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi all, The discussion around WHATWG-URL on this list, as well as my work coordinating Uri-Interop , lead me to think PHP needs a multibyte equivalent of rawurlencode(). Broadly speaking, as far as I can tell: - For an RFC 3986 URI, delimiters need to

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, There is a pre-existing userland implementation of WHATWG-URL at . Packagist reports 600K+ downloads . It is from Trevor Rowbotham, who is acknowledged in the WHATWG-URL specification itself <

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On Feb 25, 2025, at 09:55, ignace nyamagana butera > wrote: > > The problem with your suggestion is that the specification from WHATWG and > RFC3986/3987 are so different and that the function you are proposing won't > be able to cover the outcome correctly (ie give the developper all the

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi there, > On Feb 24, 2025, at 03:36, Tim Düsterhus wrote: > ... > > but had a look at the “after-action summary” thread and specifically Côme’s > response, which you apparently agreed with: > >> My take on that is more that functionality in core needs to be «perfect», or >> at least near u

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi all, In earlier discussions on the [Server-Side Request and Response objects](https://externals.io/message/108436) RFC and the [after-action sumamry](https://externals.io/message/109563), one of the common non-technical objections was that it would better be handled in userland. Seeing as t

Re: [PHP-DEV] [RFC] Modern Compression (zstd, brotli)

rying to make a standard design for all the Compression drivers and features and instead agree that things (Enums?) will and should differ from drive too driver and that'd okay. Maybe this is a bit of a new side topic from Jordi's Brotli proposal, but I think it's still relevant

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

ork". We need to understand how this could negatively impact how their systems are put together, and we definitely want to, upfront, identify anything we wouldn't normally think of, that they can spot, since they know their own codebases better than we do. We already have the composer analysis, so after we have these framework/project analysis then we can make a strongly informed decision on the impact, positively or negatively, this change will make. Many thanks, Paul

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

On Fri, Jun 21, 2024 at 10:12 AM Paul Dragoonis wrote: > > > On Thu, Jun 20, 2024 at 11:54 PM Rowan Tommins [IMSoP] < > imsop@rwec.co.uk> wrote: > >> On 19/06/2024 16:34, Larry Garfield wrote: >> >> Also, as someone who does put every file into str

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

On Thu, Jun 20, 2024 at 11:54 PM Rowan Tommins [IMSoP] wrote: > On 19/06/2024 16:34, Larry Garfield wrote: > > Also, as someone who does put every file into strict mode as a matter of > course, and appreciates the many languages that do not even have a > concept of non-strict mode (like Go or Ru

Re: [PHP-DEV] New "PECL"

On Tue, Dec 5, 2023 at 3:25 PM Paul Dragoonis wrote: > > > On Tue, Dec 5, 2023 at 3:21 PM Pierre Joye wrote: > >> On Tue, Dec 5, 2023, 10:13 PM Pierre Joye wrote: >> >> > >> > >> > You may mention https://github.com/FriendsOfPHP/pickl

Re: [PHP-DEV] New "PECL"

think I'll use this same approach for php.net/docs modernization approach. I came here to write about Pierre's Pickle project, but he replied whilst I was mid-writing this email :-) I'll add comments onto the Google Doc. Many thanks, Paul > > >

Re: [PHP-DEV] PHP 8.3.0 Released!

m/bukka/9b83d9718de090953eec989be16ba91a > > Jakub Zelenka, Eric Mann, & Pierrick Charron > What an achievement! Just giving my personal thanks to Jakub, Eric, & Pierrick, and obviously to all contributors, you all rock! :-) Looking forward to trying it out Many thanks, Paul >

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

) $secondItem = next($array) Which is simple and works, but really it's just by design that the code hasn't shifted the array pointer yet and I can cheat with current() If the pointer was shifted then I'd have to do reset(), which isn't good. array_first() for the win Many thanks,

Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework

ched PHP versions (think about centos or Debian distributions, or Docker images of PHP) Just like we've done with many things over the years, we first deprecated something and keep it in the language and in future release we remove it completely. Many thanks, Paul > Thanks. Dmitry. >

[PHP-DEV] Re: [RFC] Unicode Text Processing

On 12/15/2022 7:34 AM, Derick Rethans wrote: https://wiki.php.net/rfc/unicode_text_processing A few quick thoughts: The constructor will also convert the given text to Unicode Canonical Form. By this do you mean Normalization Form C (NFC)? "Unicode Canonical Form" isn't a phrase I'm famili

Re: [PHP-DEV] Remove warning when parsing datetime with + symbol?

On Mon, 28 Nov 2022, 16:32 Christoph M. Becker, wrote: > On 28.11.2022 at 16:50, Derick Rethans wrote: > > > On Thu, 24 Nov 2022, mickmackusa wrote: > > > >> Can anyone explain to me why it is desirable/beneficial for the DateTime > >> class to store a warning that trailing characters were ignore

Re: [PHP-DEV] RFC: StreamWrapper Support for glob()

are deeper technical reasons why this wouldn't be a good idea, because I'm not it Unless my memory is wrong, Sara was heavily involved in the initial streams API, and might be good to see what she thinks too, from an implementation POV :) Many thanks, Paul On Wed, 14 Sep 2022, 17:59 T

Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling

On Thu, 8 Sep 2022, 17:18 Tim Düsterhus, wrote: > Hi > > On 9/7/22 23:44, Larry Garfield wrote: > > Either I guess? Honestly we should decide that in advance on the list. > :-) E_WARNING+Exception in 9 is what I'd probably favor, with "Exception > now" as a second choice. > > > > I'm a new-ish

Re: [PHP-DEV] Re: Increase maximum size of an uploaded file to 50Mbyte

On Thu, 8 Sep 2022, 12:59 Christoph M. Becker, wrote: > On 08.09.2022 at 13:01, Andreas Heigl wrote: > > > On 08.09.22 12:35, Jakub Zelenka wrote: > > > >> On Wed, Sep 7, 2022 at 3:28 PM Christoph M. Becker > >> wrote: > >> > >>> On 07.09.2022 at 15:57, Misha wrote: > >>> > We spend a lot o

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

On 8/26/2022 1:28 AM, Peter Bowyer wrote: Hi Juan, On Thu, 25 Aug 2022 at 17:02, juan carlos morales < dev.juan.mora...@gmail.com> wrote: RFC: https://wiki.php.net/rfc/json_validate Thanks for bringing forward this RFC. I am in favour of this change, as you can't efficiently validate JSON i

[PHP-DEV] Executing PHP SAPI/runtime from Golang/Rust

sible, and what blockers are in our way, currently, if it's not even possible to share SAPI calls from another language runtime. Thanks for listening, Paul Dragoonis. I wrote this on my phone, so excuse typos and poor grammar :)

[PHP-DEV] Re: [Concept] Extension methods

On 8/10/2022 7:17 AM, Alex Wells wrote: This solution works, but in practice is rarely used. The reasons are: - there's no IDE completion: `$collection-> ` <- here I want IDE to auto-complete the `map` method somehow, but since it's a function this is impossible This isn't impossible. There's n

Re: [PHP-DEV] [RFC] Asymmetric visibility

On Fri, 5 Aug 2022, 20:53 Larry Garfield, wrote: > On Fri, Aug 5, 2022, at 2:27 PM, Michał Marcin Brzuchalski wrote: > > Hi Larry, > > > > pt., 5 sie 2022, 19:09 użytkownik Larry Garfield > > > napisał: > > > >> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: > >> Asymmetr

Re: [PHP-DEV] What to do with qa.php.net?

It's useful to me, as I've always been able to merge PRs on the QA site, because I've not been added to any php-web/php-src github repos since we migrated over there. However, if it's not too useful to the majority of people, then I'll still vote to delete it/move stuff. One less site for us all

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

I think the original goal of this RFC is to make PHP more expressive, and less clunky (look at Jav). This is a good goal and one much desired by the community, but I think the approach here isn't the right fit or way to achieve it Writing code in strings is a DX nightmare, and static analysis cha

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

On Thu, Mar 3, 2022 at 8:51 PM G. P. B. wrote: > > Moreover, at the time of writing this, none of the following programming > languages have any messages in regards to the war: > - Python (https://www.python.org/) > - TypeScript (https://www.typescriptlang.org/) > - Rust (https://www.rust-lang.org

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

On Wed, Mar 2, 2022 at 11:11 PM Paul Crovella wrote: > On Wed, Mar 2, 2022 at 1:08 PM Stanislav Malyshev > wrote: > > > > That said, if somebody were to design a logo version with Ukraine flag > > > > In case anyone has use for it: https://svgshare.com/i/epJ.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

On Wed, Mar 2, 2022 at 1:08 PM Stanislav Malyshev wrote: > > That said, if somebody were to design a logo version with Ukraine flag > In case anyone has use for it: https://svgshare.com/i/epJ.svg Colors are #0057b7 and #ffd700, from https://en.wikipedia.org/wiki/Flag_of_Ukraine#Design, with a wh

Re: [PHP-DEV] header() allows arbitrary status codes

On Thu, 23 Dec 2021, 00:06 David Gebler, wrote: > On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker > wrote: > > > 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 s

Re: [PHP-DEV] [VOTE] Locale-independent case conversion

On Thu, Nov 25, 2021 at 3:14 AM Tim Starling wrote: > > On 25/11/21 7:57 pm, Côme Chilliet wrote: > > > To reuse the example from the RFC, if I want to convert a UTF string to > > uppercase using Turkish rules and get dotted capital I, what should I use? > > For case-insensitive comparison you ca

Re: [PHP-DEV] [VOTE] Migrating to GitHub issues

Been wanting this since we first setup github. I'm glad we're seriously reconsidering it again. Nikita, If you want any help, with designing/writing scripts to perform the data migration, then just DM me (Twitter?) and I will put in the time/effort to make it happen. Just let me know. Thanks.

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

cProperties] requires making classes that rely on dynamic > properties explicit and prevents accidental use of dynamic properties It may help prevent some, but others can skate through on happenstance. Cheers, Paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

On Wed, Aug 25, 2021 at 3:03 AM Nikita Popov wrote: > > Hi internals, > > I'd like to propose the deprecation of "dynamic properties", that is > properties that have not been declared in the class (stdClass and > __get/__set excluded, of course): > > https://wiki.php.net/rfc/deprecate_dynamic_prop

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

On Thu, Jun 17, 2021 at 11:01 PM Craig Francis wrote: > > As there’s been no issues raised with supporting integers, and doing so > will help adoption, the implementation will be updated to allow them. > > Now to choose the name, with the options is_known() from Joe and > is_trusted() from Moritz:

Re: [PHP-DEV] Allow objects in define()

On Mon, Jun 14, 2021 at 7:47 PM Larry Garfield wrote: > On Mon, Jun 14, 2021, at 9:35 AM, Nikita Popov wrote: > > Hi internals, > > > > With the introduction of enums, it's now possible for constants to hold > > objects. However, this works only when using the `const X = Y` syntax, > not > > when

Re: [PHP-DEV] Re: Policy for procedural style in new additions

On Thu, Jun 3, 2021 at 3:07 PM Christoph M. Becker wrote: > > I'd take a step at a time, and start with "prohibit introduction of new > dual APIs" only. > That sort of RFC doesn't really buy anything. It'd take a 2/3 vote to override it which is the same as what it'd take to introduce a dual API

Re: [PHP-DEV] [RFC] Partial function application

On Fri, May 14, 2021 at 4:44 PM Aaron Piotrowski wrote: > > My issue is the dual-meaning of ? in the current proposal. In `foo(?, 42)`, > the ? represents a single argument, but adding a trailing ? (such as in > `foo(?, 42, ?)`) represents any number of arguments. Would it perhaps make > sense

Re: [PHP-DEV] [RFC] Partial function application

On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski wrote: > > Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as > `$partial = foo(?, 42)`. > > If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z` > or should the call error as providing too few arg

Re: [PHP-DEV] [RFC] Partial function application

cludes an implementation by Joe Watkins that is already about 95% > complete. (There's some edge cases he's still sorting out, but all of the > typical cases should work already.) Most of the design work comes from Levi > Morrison and Paul Crovella. I helped out with the tes

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

On Mon, 29 Mar 2021, 08:51 Paul Dragoonis, wrote: > > > On Mon, 29 Mar 2021, 02:30 Rasmus Lerdorf, wrote: > >> On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote: >> >> > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella >> > wrote: >> > >>

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

On Mon, 29 Mar 2021, 02:30 Rasmus Lerdorf, wrote: > On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote: > > > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella > > wrote: > > > >> You might consider requiring commits be signed while you're at it. > >>

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

You might consider requiring commits be signed while you're at it. On Sun, Mar 28, 2021 at 3:53 PM Nikita Popov wrote: > > 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 > exact

Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals

Hi Rowan and all, I apologize in advance for the wall-of-text; the short questions lead to long answers. > On Jan 2, 2021, at 12:56, Rowan Tommins wrote: > > On 01/01/2021 20:31, Paul M. Jones wrote: > >> The complaints against the incomplete and inconsistent immutability

Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals

(but failed) to predict would be more trouble than it was worth. The fewer people who use it, the better. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1p

Re: [PHP-DEV] Documentation is on git

> On Dec 30, 2020, at 08:19, Andreas Heigl wrote: > > Hey folks! > > The PHP-Documentation has moved to git! Absolutely phenomenal. Well done all around! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://lea

Re: [PHP-DEV] Re: [RFC] Phasing out Serializable

> an RFC that mandates what should happen in 10.0, maybe > 10 years into the future feels a bit farfetched. It's more of a default unless another RFC changes the plan rather than a mandate. Given the plan here it seems a reasonable default. -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] [RFC] Short-match

On Mon, Dec 14, 2020 at 1:23 PM Sara Golemon wrote: > > On Mon, Dec 14, 2020 at 2:24 PM Doug Nelson wrote: > > > Both you and Sara at different points have talked about thinking was bad > > practice, but I've not read anything compelling about why it should be > > considered as such. > > > > > I'

Re: [PHP-DEV] [RFC] Enumerations

On Tue, Dec 8, 2020 at 10:14 AM Larry Garfield wrote: > > > Hi Paul. Although we're on hold for a bit while Ilija makes some changes in > direction (see previous email) I'm looking forward to seeing the results. > > Enumerations, as a general concept, are statel

Re: [PHP-DEV] [RFC] Enumerations

On Sun, Dec 6, 2020 at 7:49 AM Larry Garfield wrote: > > On Sun, Dec 6, 2020, at 9:11 AM, Rowan Tommins wrote: > > > Note that Larry's longer term plan is for "algebraic data types", > > including "tagged unions": https://wiki.php.net/rfc/adts Unlike > > straight-forward enum cases, these are not

Re: [PHP-DEV] [RFC] Enumerations

On Sun, Dec 6, 2020 at 7:12 AM Rowan Tommins wrote: > > On 06/12/2020 00:17, Paul Crovella wrote: > >> enum cases have no state > > Unless there's a bit left out from this RFC this is not completely > > true, you've just limited them to annoying ways

Re: [PHP-DEV] [RFC] Enumerations

On Fri, Dec 4, 2020 at 7:00 PM Larry Garfield wrote: > > > Dec 4, 2020 7:37:51 PM Paul Crovella : > > > On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield > > wrote: > >> > >> Greetings, denizens of Internals! > >> > >> Ilija Tovi

Re: [PHP-DEV] [RFC] Enumerations

On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield wrote: > > Greetings, denizens of Internals! > > Ilija Tovilo and I have been working for the last few months on adding > support for enumerations and algebraic data types to PHP. This is a > not-small task, so we've broken it up into several stages

Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage

lass of bugs relating to > $GLOBALS handling in internal functions. > > https://wiki.php.net/rfc/restrict_globals_usage > Big +1 -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem

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

On Tue, Dec 1, 2020 at 10:23 AM G. P. B. wrote: > > On Tue, 1 Dec 2020 at 18:07, Paul Crovella wrote: >> >> On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker wrote: >> > >> > On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote: >> > >> &

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

On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker wrote: > > On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote: > > > Am 01.12.20 um 18:24 schrieb Christoph M. Becker: > >> > >>> In PHP 7, this returns FALSE: > >>> > >>> php -r 'var_dump(is_file("ab\0c"));' > >>> > >>> In PHP 8, the same c

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

On Tue, Dec 1, 2020 at 9:48 AM G. P. B. wrote: > > > On Tue, 1 Dec 2020 at 17:46, G. P. B. wrote: >> >> On Tue, 1 Dec 2020 at 17:45, Paul Crovella wrote: >>> >>> On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker >>> wrote: >>> > &g

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

On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker wrote: > > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote: > > > PHP 8 is stricter in checking input data then PHP 7. This is good but > > has some side effects for is_file(), is_dir() and similar functions when > > invalid paths are pas

Re: [PHP-DEV] List of attributes

come to your house and lynch you for asking them to vote on the same thing > yet again. It just ain't gonna happen. Yes, because we voted repeatedly until the voters "got it right" -- and now there cannot ever be another vote on it again. -- Paul M. Jones pmjo...@pmjones.

Re: [PHP-DEV] Attribute Syntax Revote

... > I remember that you were one of the people to request this :-) ... but to be clear, I noted that the proper thing to do was to restart the two-week discussion period, thus resetting the time at which the vote could be held. Obviously that was not done. -- Paul M. Jones pmjo...@pmj

[PHP-DEV] Attribute Syntax Revote

f you have not done so yet: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting > > Please note that there are now 6 options. > > cheers, > Derick > -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

Re: [PHP-DEV] Community vote on RFCs

On Wed, Aug 19, 2020 at 4:19 PM Benjamin Morel wrote: >> >> 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 f

Re: [PHP-DEV] Community vote on RFCs

On Wed, Aug 19, 2020 at 3:35 PM Benjamin Morel wrote: > > Hi Paul! > > I'm writing off list to avoid polluting the thread too much. I'm writing on list because it's weird that you call this pollution. > Could you please care to explain your negative reaction to t

Re: [PHP-DEV] Community vote on RFCs

-1 On Wed, Aug 19, 2020 at 2:28 PM Benjamin Morel wrote: > > 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. > > Unde

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

RFC Version to be, so that voters will be fully informed > by the RFC once the vote re-starts on Tuesday. I'm very glad to hear that; the vote should not re-start on Tuesday, though, since we'll need 2 weeks to discuss these important and substantial revisions. -- Paul M. Jone

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

n period can begin. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

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

egular. This vote should be canceled, regarded as null and void; the RFC fully updated with the results of the discussion thus far, including all the notes provided by Theodore; a new 2-week pre-vote discussion initiated; and *then* a new vote can be initiated after that 2 week period.

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

exists, which I submit it does not -- but that's a separate topic.) -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

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

st 18th. So, a week+ early, then? Surely that means the current vote null and void, to be reset entirely following a proper discussion period -- one without concurrent voting. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/m

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

> On Aug 12, 2020, at 10:25, Sara Golemon wrote: > > If others agree that it's premature, we can stop the vote, > but I'm not inclined to disrupt the process over such a small variance. It's premature. If we can't follow our own rules, why even hav

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

a terrible > choice, and are you sure you're okay with it? Maybe -- but we can always vote *yet again* on this, until the voters *finally* get it right. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

s RFC *must* go to a vote (and that is not a given), then adding a primary vote along the lines of "Are you okay with re-voting on the attribute syntax for PHP 8.0?" would go a long way toward alleviating the "vote until the voters get it 'right'" problem. -- Paul M. J

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

Hi Michal, > On Jul 29, 2020, at 01:13, Michał Marcin Brzuchalski > wrote: > > Hi Paul, > > wt., 28 lip 2020 o 20:56 Paul M. Jones napisał(a): > >> ... >> Let's count. + is "change away from @@ to anything else", - is "stay with &

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

> On Jul 28, 2020, at 14:15, Ben Ramsey wrote: > >> On Jul 28, 2020, at 14:10, Paul M. Jones wrote: >> >>> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: >>> >>>> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: >>>> >>>&g

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: > >> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: >> >> Now, it may be that #[] or <<>> or something else actually is "better" in >> some sense that cannot be articulated. But if there

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

++ Rafael Dohms: +? Alexander Berl: -? Chris Emerson: -- Tamas Erdelyi: ?? Phili Weinke: ?? Trent: ++ Juriaan Ruitenberg: ++ Mehran: ++ Stephan Hochdorfer: ?? Cees-Jan Kiewiet: ?? Tom Witkowski: ++ Matiss: ++ Henry Paradiz: -- Saif: ?? Paul Redmond: ?? Marco Pivetta: ++ Simon Champion: ?? @eimihar

RE : [PHP-DEV] RFC proposal: Spread Operator for Array Destructuring Assignment

Well, I think this answer the first question. Since consistency is king, why not just applying the same behavior than without spread operator? What do you think ? De : Côme Chilliet Envoyé le :mercredi 3 juin 2020 17:02 À : internals@lists.php.net

[PHP-DEV] RFC proposal: Spread Operator for Array Destructuring Assignment

several cases where this could be very useful and make my code shorter. Best regards, Paul Laffitte paul.laffi...@epitech.eu<mailto:paul.laffi...@epitech.eu> Student Promotion 2021 {EPITECH.} Montpellier +336.01.04.24.96

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

> On Apr 9, 2020, at 02:29, Côme Chilliet > wrote: > > Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit : > >> **Lesson:** Of functionality that can be accomplished in userland, only >> trivial/simple functionality is acceptable. > > My take o

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

great, but having it optionally generate pleasantly-readable code (e.g. to be used as $actual in tests) would also be great. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://l

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

[Publish Your Failures]: http://paul-m-jones.com/post/2013/10/28/publish-your-failures-or-the-way-of-all-frameworks/ Again, and as ever, thanks to everyone who provided useful feedback on this RFC. * * * ## Summary of Objections The non-technical objections had more overlap among voters than t

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

> On Mar 20, 2020, at 08:31, Paul M. Jones wrote: > > Hi all, > > I have opened the vote on Server-Side Request and Response Objects at > <https://wiki.php.net/rfc/request_response>. > > The voting period will close two weeks from today on Fri 03 Apr 2020. Th

Re: [PHP-DEV] [RFC] Change default PDO error mode

ions as the error mode. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: h

Re: [PHP-DEV] [RFC] Constructor Property Promotion

> On Mar 26, 2020, at 08:30, Nikita Popov wrote: > > Hi internals, > > I would like to submit the following RFC for your consideration: > https://wiki.php.net/rfc/constructor_promotion Big fan. Thanks for this. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jone

[PHP-DEV] [VOTE] Server-Side Request and Response Objects (v2)

Hi all, I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>. The voting period will close two weeks from today on Fri 03 Apr 2020. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications

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

/concerns you may have. Unless there are objections (or new substantive discussion) I plan to open voting tomorrow or Friday. Thanks to everyone who has participated so far! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp

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

27;ll keep the new prefix, and I'll update the RFC accordingly. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Developmen

  1   2   3   4   5   6   7   >