Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 28, 2024, at 3:07 AM, Michael Morris wrote: > On Thu, Jun 27, 2024 at 8:16 PM Mike Schinkel > wrote: > node_modules IMO is one of the worse things about the JavaScript ecosystem. > Who has not seen the meme about node_modules being worse than a black hole? >

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024, at 08:32, Michael Morris wrote: > Not replying to anyone in particular and instead doing a mild reset taking > into account the discussion that has gone before. > > So, I want to import a package. I'll create an index.php file at the root of > my website and populate it

Re: [PHP-DEV] [RFC] Make the GMP class final

On Sat, Jun 29, 2024, at 03:05, Ben Ramsey wrote: > > On Jun 28, 2024, at 18:53, Gina P. Banyard wrote: > > > > Hello internals, > > > > I would like to present an RFC to make the GMP class final: > > https://wiki.php.net/rfc/gmp-final > > > > This is short and to the point, and I intend to ope

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

On 28/06/2024 22:06, Máté Kocsis wrote: Hi Everyone, I've been working on a new RFC for a while now, and time has come to present it to a wider audience. Last year, I learnt that PHP doesn't have built-in support for parsing URLs according to any well established standards (RFC 1738 or the W

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote: > > > On Fri, Jun 28, 2024 at 12:55 PM Rob Landers wrote: >> __ >> >> >>> 3. The private/protected distinction is fairly meaningless for the >>> functions that implement overloads, because the privacy of the function is >>> ignored complet

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 11:01, Rob Landers wrote: > On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote: >> >> >> On Fri, Jun 28, 2024 at 12:55 PM Rob Landers wrote: >>> __ >>> >>> 3. The private/protected distinction is fairly meaningless for the functions that implement overloa

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote: >>> 4. The `static` distinction is also fairly meaningless, as in PHP there is >>> no situation possible where an operator overload can occur WITHOUT it >>> operating on objects themselves. >> >> For this, that is the wrong approach. The act

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

> On 29 Jun 2024, at 06:03, Bilge wrote: > > On 28/06/2024 22:35, Niels Dossche wrote: >> - Why did you choose UrlParser to be a "static" class? > > Because "static class" is the hip new cool ;) > > Bilge I would argue that for 90%+ of cases, static *userland* classes are used because of (

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 28, 2024, at 10:12 AM, Rowan Tommins [IMSoP] > wrote: > Namespaces don't require autoloading, and autoloading doesn't require one > file per class. No they do not, but the design of each was heavily intertwined with each other resulting in a less than opti

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 29, 2024, at 2:32 AM, Michael Morris wrote: > > Not replying to anyone in particular and instead doing a mild reset taking > into account the discussion that has gone before. > > So, I want to import a package. I'll create an index.php file at the root of > my website and populate it

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 28, 2024, at 7:45 AM, Rob Landers > wrote: >> Fast forward a bit - PHP 5.3, and the introduction of namespaces were >> introduced to deal with the overloaded symbol tables. They are a bit a >> hotwire as (if I'm not mistaken, it's been a couple years since I re

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On 29 June 2024 07:32:58 BST, Michael Morris wrote: > So why this instead of composer? Well, a native implementation should be > faster, but also it might be able to deal with php extensions. Building a package manager is hard, and getting a package manager adopted requires the network effe

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024, at 11:41, Mike Schinkel wrote: >> On Jun 28, 2024, at 7:45 AM, Rob Landers wrote: >>> Fast forward a bit - PHP 5.3, and the introduction of namespaces were >>> introduced to deal with the overloaded symbol tables. They are a bit a >>> hotwire as (if I'm not mistaken, it's

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

> On 29 Jun 2024, at 04:48, Niels Dossche wrote: > > - It's a bit of a shame that the PSR interface treats queries as strings. > In Javascript we have the URLSearchParams class that we can use as a > key-value storage for query parameters. > This Javascript class also handles escaping them ni

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On 29 June 2024 08:06:57 BST, Mike Schinkel wrote: >The takeaways that I think would be useful are PHP modules are: > >1. Imports >2. Import aliases >3. Module-level consts >4. Module-level init() functions >5. Module-level vars with initialization >6. Module-level functions >7. One directory

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

On Sat, Jun 29, 2024, at 11:57, Stephen Reay wrote: > > > > On 29 Jun 2024, at 04:48, Niels Dossche wrote: > > > > - It's a bit of a shame that the PSR interface treats queries as strings. > > In Javascript we have the URLSearchParams class that we can use as a > > key-value storage for query

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> > On Jun 29, 2024 at 6:20 AM, (mailto:imsop@rwec.co.uk)> wrote: > > > > On 29 June 2024 08:06:57 BST, Mike Schinkelwrote: > >The takeaways that I think would be useful are PHP modules are: > >1. > Imports >2. Import aliases >3. Module-level consts

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024, at 12:56, Mike Schinkel wrote: > >> Most of it sounds completely impractical to apply in retrospect to an >> existing one with millions of users - apart from the bits we actually >> already have, like points 3 and 6. >> >> > You say it is impractical, you claim millions

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 29, 2024, at 7:14 AM, Rob Landers wrote: >> You say it is impractical, you claim millions of users, but you don't >> address why the specific features are impractical. >> >> They are no more impractical than any other new language features PHP has >> added in recent years (and I am not

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

On 29/06/2024 10:31, Stephen Reay wrote: On 29 Jun 2024, at 06:03, Bilge wrote: On 28/06/2024 22:35, Niels Dossche wrote: - Why did you choose UrlParser to be a "static" class? Because "static class" is the hip new cool ;) Bilge I would argue that for 90%+ of cases, static *userland* class

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On 29 June 2024 11:56:43 BST, Mike Schinkel wrote: >That list is just package-specific, nothing about syntax, data types, control >structures, package management, etc. etc. It includes fundamental design decisions like "what does a class name look like", and "how are classes identified acro

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

Hi, > On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote: >>> 4. The `static` distinction is also fairly meaningless, as in PHP there is >>> no situation possible where an operator overload can occur WITHOUT it >>> operating on objects themselves. >> >> For this, that is the wrong approach. Th

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 29, 2024, at 8:27 AM, Rowan Tommins [IMSoP] > wrote: > On 29 June 2024 11:56:43 BST, Mike Schinkel wrote: > >> That list is just package-specific, nothing about syntax, data types, >> control structures, package management, etc. etc. > > It includes fundamental design decisions like

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote: >> On Jun 29, 2024, at 7:14 AM, Rob Landers wrote: >>> You say it is impractical, you claim millions of users, but you don't >>> address why the specific features are impractical. >>> >>> They are no more impractical than any other new langu

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 14:28, Saki Takamachi wrote: > > Hi, > >> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote: > 4. The `static` distinction is also fairly meaningless, as in PHP there > is no situation possible where an operator overload can occur WITHOUT it > operating on

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

Hi, >> Here are my thoughts on your code. >> >> In theory, inheriting from this "improved GMP class" would allow overloading >> of computational operators. >> >> In effect, this acts like a "calcable interface", with the constructor >> passing in meaningless values to the parent constructor an

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

I'll add a little more. > I would like to state my opinion on this matter, making it clear that I am of > the opinion that "GMP class should be final." > > First of all, to meet the requirements that are the basis of this discussion, > it is not actually necessary to expose the calculation logi

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 3:52 AM Rob Landers wrote: > I don't think that is correct... > Correct or not it's irrelevant trivia. While this looks good on paper, you're going to have to standardize how > packages are accessed (API calls, etc) so they can be used in this file, or > literally anyone

Fwd: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 5:40 AM Mike Schinkel wrote: > However, be aware that in a Go project repo you are likely to have only > one `go.mod` — or multiple if you have numerous CLI apps being generated — > whereas every directory with Go code is a package (which I think is > equivalent to what yo

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 5:43 AM Mike Schinkel wrote: > > On Jun 28, 2024, at 10:12 AM, Rowan Tommins [IMSoP] > wrote: > > > Also, the JS insistence on having a separate package for every tiny > function is a common source of criticism, so personally I am very happy > that PHP packages are genera

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 7:28 AM, Saki Takamachi wrote: > Hi, > >> On Sat, Jun 29, 2024, at 02:13, Jordan LeDoux wrote: > 4. The `static` distinction is also fairly meaningless, as in PHP there > is no situation possible where an operator overload can occur WITHOUT it > operating on o

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 16:19, Saki Takamachi wrote: > Hi, > > >> Here are my thoughts on your code. > >> > >> In theory, inheriting from this "improved GMP class" would allow > >> overloading of computational operators. > >> > >> In effect, this acts like a "calcable interface", with the cons

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 7:15 AM Rob Landers wrote: > > With a bit of finangling, you can actually port JavaScript line-for-line > to PHP, but not the other way around. > JavaScript uses prototypical inheritance, and any program that leverages that aspect of it will be IMPOSSIBLE to port to PHP l

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

> On Jun 29, 2024, at 10:16, Larry Garfield wrote: > > For clarity (since I know from experience it's helpful to RFC authors to have > a concrete sense of votes in advance): I will be voting No on this RFC. As > both Jordan and Saki have explained, it's a hideous hack that doesn't look > like

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 29, 2024, at 03:11, Rob Landers wrote: > > On Sat, Jun 29, 2024, at 03:05, Ben Ramsey wrote: >> > On Jun 28, 2024, at 18:53, Gina P. Banyard wrote: >> > >> > Hello internals, >> > >> > I would like to present an RFC to make the GMP class final: >> > https://wiki.php.net/rfc/gmp-final

Re: [PHP-DEV] [RFC] Static class

Hi Ayesh, On 24/06/2024 08:53, Ayesh Karunaratne wrote: - Why is it a class-level flag and not an attribute (similar to the `#[Override]` attribute in PHP 8.3) ? I believe Tim already answered this, and I understood his reasoning to be that keywords are used when they modify behaviour in a w

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024, at 17:27, Michael Morris wrote: > > > On Sat, Jun 29, 2024 at 7:15 AM Rob Landers wrote: >> __ >> >> With a bit of finangling, you can actually port JavaScript line-for-line to >> PHP, but not the other way around. > > JavaScript uses prototypical inheritance, and any

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

On 2024-06-28 23:06, Máté Kocsis wrote: Hi Everyone, I've been working on a new RFC for a while now, and time has come to present it to a wider audience. Last year, I learnt that PHP doesn't have built-in support for parsing URLs according to any well established standards (RFC 1738 or the

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

I have added one more deprecation Deprecate the second parameter to mysqli_store_result().

Re: [PHP-DEV] [RFC] Make the GMP class final

On 29/06/2024 16:55, Ben Ramsey wrote: If this RFC passes to make the \GMP class final, and your RFC passes to allow extending the \GMP class, then I think we’re in a sort of weird limbo state. Presumably in that case whichever RFC passes last would have to take precedence. The community is al

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 29, 2024, at 12:01, Barney Laurance wrote: > > On 29/06/2024 16:55, Ben Ramsey wrote: >> If this RFC passes to make the \GMP class final, and your RFC passes to >> allow extending the \GMP class, then I think we’re in a sort of weird >> limbo state. > Presumably in that case whichever

Re: [PHP-DEV] [RFC] Make the GMP class final

Hi, >> If this RFC passes to make the \GMP class final, and your RFC passes to >> allow extending the \GMP class, then I think we’re in a sort of weird >> limbo state. > Presumably in that case whichever RFC passes last would have to take > precedence. The community is allowed to change its mind

Re: [PHP-DEV] [RFC] Make the GMP class final

Hi, > Sure, it’s allowed to change its mind, but if we bring this for a vote in two > weeks, and then we vote a week later for the other (or even at the same > time), I would see the results of those votes as conflicting viewpoints and > not as the community changing its mind within the span of

Re: [PHP-DEV] [RFC] Make the GMP class final

> On Jun 29, 2024, at 12:25, Saki Takamachi wrote: > > Hi, > >> Sure, it’s allowed to change its mind, but if we bring this for a vote in >> two weeks, and then we vote a week later for the other (or even at the same >> time), I would see the results of those votes as conflicting viewpoints an

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

> On Jun 29, 2024, at 03:20, nyamsprod the funky webmaster > wrote: > > Therefore, I would rather suggest we ALSO include support for RFC3986 and > RFC3987 specification properly and give both specs a go (at the same time!) > and a clear way to instantiate your `Url` with one or the other spec

Re: [PHP-DEV] [RFC] Make the GMP class final

On Sat, Jun 29, 2024, at 19:31, Ben Ramsey wrote: > > On Jun 29, 2024, at 12:25, Saki Takamachi wrote: > > > > Hi, > > > >> Sure, it’s allowed to change its mind, but if we bring this for a vote in > >> two weeks, and then we vote a week later for the other (or even at the > >> same time), I w

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sat, Jun 29, 2024, at 17:37, Ben Ramsey wrote: > > On Jun 29, 2024, at 10:16, Larry Garfield wrote: > > > > For clarity (since I know from experience it's helpful to RFC authors to > > have a concrete sense of votes in advance): I will be voting No on this > > RFC. As both Jordan and Saki h

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Thu, Jun 27, 2024 at 4:33 AM Michael Morris wrote: > Hello all. This is a ramble of an idea that's managed to run around my > head for a few days now. It isn't fully formed, but I've ran the thought > experiment as far as I can on my own and want to share it with all of you. > > If you got thi

Re: [PHP-DEV] [RFC] Make the GMP class final

On Sat, Jun 29, 2024, at 19:52, Rob Landers wrote: > On Sat, Jun 29, 2024, at 19:31, Ben Ramsey wrote: >> > On Jun 29, 2024, at 12:25, Saki Takamachi wrote: >> > >> > Hi, >> > >> >> Sure, it’s allowed to change its mind, but if we bring this for a vote in >> >> two weeks, and then we vote a wee

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Friday, 28 June 2024 at 18:46, Rob Landers wrote: > Hello internals, > > I'd like to introduce a new RFC: > https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP > extension to support a limited set of operator overriding to developers. It's > designed to be limited and rel

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 2:20 PM David Gebler wrote: > On Thu, Jun 27, 2024 at 4:33 AM Michael Morris wrote: > >> Hello all. This is a ramble of an idea that's managed to run around my >> head for a few days now. It isn't fully formed, but I've ran the thought >> experiment as far as I can on my

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

On Fri, 28 Jun 2024, at 21:06, Máté Kocsis wrote: > […] add a WHATWG compliant URL parser functionality to the standard library. > The API itself is not final by any means, the RFC only represents how I > imagined it first. > > You can find the RFC at the following link: > https://wiki.php.net/

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

2024年4月9日(火) 7:55 youkidearitai : > > Mainly review and approve pull request to mbstring extension. > (probably everything related to Unicode and other character encoding) > Alex Dowad (alexdowad) suggested that give to me. > https://github.com/php/php-src/pull/13906#issuecomment-2041585626 > > --

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> > If one can easily use a function incorrectly in a way that is not > *immediately* apparent, then I consider the function to be badly > designed. > Does that philosophy also cover preg_quote()? I've lost count of the number of times that I've seen it used in Stack Overflow answers without a se

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

On Sat, Jun 29, 2024 at 9:27 PM Michael Morris wrote: > > Near universal unity?? You're forgetting Wordpress, which has massive PHP > market share (more than 50% of PHP backed websites - well more than > depending on which survey you cite) and DOES NOT USE COMPOSER. And it DOES > NOT USE PSR-4 e

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

Hello internals, I've updated the RFC to include final-ish examples (barring any further constructive feedback), a prototype implementation, and an objections section. Cheers, Rob

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

Hi Larry, Thank you very much for your feedback! I think I have already partially answered some of your questions in my previous email to Niels, but let me answer your other questions below: * I... do not understand the point of having public properties AND > getters/withers. A readonly class wi

[PHP-DEV] Bumping minimum Apache version to 2.4

Hello, Perhaps you're not aware that the PHP build system currently still supports building apache2handler SAPI for Apache 2.0 and 2.2 branches. Apache 2.2 has been marked as EOL in December 2017 and doesn't receive security patches. Also, most Linux distributions and packages mostly support 2.4 a

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

Hi, > Hello internals, > > I've updated the RFC to include final-ish examples (barring any further > constructive feedback), a prototype implementation, and an objections section. > > Cheers, > > Rob It seems like the "hack" I mentioned is still possible, am I misunderstanding something? An

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

On Saturday, 29 June 2024 at 22:23, mickmackusa wrote: >> If one can easily use a function incorrectly in a way that is not >> *immediately* apparent, then I consider the function to be badly >> designed. > > Does that philosophy also cover preg_quote()? I've lost count of the number > of times

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sun, Jun 30, 2024, at 01:28, Saki Takamachi wrote: > Hi, > > > Hello internals, > > > > I've updated the RFC to include final-ish examples (barring any further > > constructive feedback), a prototype implementation, and an objections > > section. > > > > Cheers, > > > > Rob > > It seems

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

> > It mirrors the interface, but it can’t be swapped out for a UriInterface > instance, especially since it can’t be extended, so I wouldn’t consider it > compatible. I would still need to write a compatibility layer that composes > Url\Url and implements UriInterface. > I guess my words were sli

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

Hi Niels, First of all, thank you for your support! Why did you choose UrlParser to be a "static" class? Right now it's just a > fancy namespace. That's a good question, let me explain the reason: one of my major design goals was to make the UrlParser class to be extendable and configurable (e.

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 29, 2024, at 9:15 AM, Rob Landers wrote: > On Sat, Jun 29, 2024, at 13:43, Mike Schinkel wrote: >>> On Jun 29, 2024, at 7:14 AM, Rob Landers wrote: You say it is impractical, you claim millions of users, but you don't address why the specific features are impractical. >>

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 29, 2024, at 6:28 PM, David Gebler wrote: > > On Sat, Jun 29, 2024 at 9:27 PM Michael Morris wrote: > > Near universal unity?? You're forgetting Wordpress, which has massive PHP > market share (more than 50% of PHP backed websites - well more than depending > on which survey you cit

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> On Jun 29, 2024, at 10:57 AM, Michael Morris wrote: > On Sat, Jun 29, 2024 at 5:40 AM Mike Schinkel wrote: >> However, be aware that in a Go project repo you are likely to have only one >> `go.mod` — or multiple if you have numerous CLI apps being generated — >> whereas every directory with G

Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

On Sun, Jun 30, 2024, at 06:59, Rob Landers wrote: > > > On Sun, Jun 30, 2024, at 01:28, Saki Takamachi wrote: >> Hi, >> >> > Hello internals, >> > >> > I've updated the RFC to include final-ish examples (barring any further >> > constructive feedback), a prototype implementation, and an objec