Re: [PHP-DEV] [RFC] Default expression

(TL;DR; Down the thread a bit I put together a concrete example of why I'm opposed to this RFC) On Aug 26 2024, at 12:44 am, Mike Schinkel wrote: > Speaking only to #1 for the moment, there are many different places in PHP > where certain expressions make no sense either, yet I do not see those

Re: [PHP-DEV] [RFC] Default expression

This is a general comment so not replying to anyone in particular hence the top-posting (but with some bottom-posts in particular reply below.) The RFC — which I am neither pro nor con for — proposes allowing default to be an expression, and while many like and support the RFC others are (not qu

Re: [PHP-DEV] [RFC] Default expression

On Aug 25 2024, at 6:42 pm, Bilge wrote: > On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote: > > It doesn't, unfortunately, persuade me that the behaviour proposed is > > sensible. > > It should. But since it has apparently failed in that regard, I suggest you > take me up on my challenge to i

Re: [PHP-DEV] [RFC] Default expression

On Aug 25 2024, at 5:51 pm, Bilge wrote: > If you believe I am incorrect about this, I encourage you to submit a > (working) Bison patch to demonstrate how a restricted expression grammar > subset can still recurse with the unrestricted superset, then we can start > having this discussion mor

Re: [PHP-DEV] State of Generics and Collections

To throw one more question into the pot, I'd like to raise the possibility of wanting typedefs. (To use the old C/C++ term, the latter also allows a "type alias" syntax that does much the same thing.) To use an example from the blog post: function f(List> $entries): Map {...} there need not b

Re: [PHP-DEV] [RFC] Default expression

On 25 August 2024 23:42:20 BST, Bilge wrote: >On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote: >> It doesn't, unfortunately, persuade me that the behaviour proposed is >> sensible. > >It should. But since it has apparently failed in that regard, I suggest you >take me up on my challenge to i

Re: [PHP-DEV] [RFC] Default expression

On 26.8.2024 00:31:57, Rowan Tommins [IMSoP] wrote: I'm not an expert on parsers, and never claimed to be, so it's not particularly surprising to me that I've overlooked a reason why "expr ?: default" can't be included without also including "default ?: expr", and will just have to take your wo

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote: It doesn't, unfortunately, persuade me that the behaviour proposed is sensible. It should. But since it has apparently failed in that regard, I suggest you take me up on my challenge to implement the grammar you want with a patch and you will

Re: [PHP-DEV] [RFC] Default expression

On 25 August 2024 22:51:45 BST, Bilge wrote: >Great! I'm glad we're finally getting to this, because I think this is what >you, and everyone advocating for a restricted grammar, is actually missing. >You think you've caught me in some kind of "gotcha" moment, but fair warning, >I'm about to

Re: [PHP-DEV] [RFC] Decoding HTML and the Ambiguous Ampersand

> On Aug 25, 2024, at 4:17 PM, Máté Kocsis wrote: > > Hi Christoph, Dennis, > >> Well, I don't think it would be a big deal to move the bundled lexbor to >> somewhere where it is always available. I mean, so far it's only used >> by ext/dom so it's bundled there, but if other parts of the php-

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 22:09, Rowan Tommins [IMSoP] wrote: On 25 August 2024 21:00:03 BST, Bilge wrote: class Suspension {     /** * @param int $delay Specifies the delay in milliseconds. */     public function suspend(int $delay = 1_000) {     var_dump($delay);     } } class MySus

Re: [PHP-DEV] [RFC] Default expression

On 25 August 2024 21:29:45 BST, John Bafford wrote: >This is only by current convention. It used to be that parameter names were >not part of the API contract, but now with named parameters, they are. Indeed, and it remains highly controversial among library authors, and is even used as a j

Re: [PHP-DEV] [RFC] Decoding HTML and the Ambiguous Ampersand

Hi Christoph, Dennis, Well, I don't think it would be a big deal to move the bundled lexbor to > somewhere where it is always available. I mean, so far it's only used > by ext/dom so it's bundled there, but if other parts of the php-src code > base would use it, we could put it elsewhere. > Exac

Re: [PHP-DEV] [RFC] Default expression

On 25 August 2024 21:00:03 BST, Bilge wrote: >class Suspension { >    /** > * @param int $delay Specifies the delay in milliseconds. > */ >    public function suspend(int $delay = 1_000) { >    var_dump($delay); >    } >} > >class MySuspension extends Suspension { >    /** > * @

Re: [PHP-DEV] State of Generics and Collections

On Mon, Aug 19, 2024, at 12:08 PM, Derick Rethans wrote: > Hi! > > Arnaud, Larry, and I have been working on an article describing the > state of generics and collections, and related "experiments". > > You can find this article on the PHP Foundation's Blog: > https://thephp.foundation/blog/2024/0

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 10:29 AM, Bilge wrote: > On 25/08/2024 14:35, Larry Garfield wrote: >> The approach here seems reasonable overall. The mental model I have from >> the RFC is "yoink the default value out of the function, drop it into this >> expression embedded in the function call, and

Re: [PHP-DEV] [RFC] Default expression

> public function suspend(float|int|null $delay = null) { > parent::suspend((int)(($delay ?? 0) * 1000) ?: default); > } > } > > new MySuspension()->suspend(2.2345); // int(2234) > Not only have I demonstrated the need to use multiplication or division > to change the scale, but also the need to

Re: [PHP-DEV] [RFC] Default expression

On Aug 25, 2024, at 14:46, Rowan Tommins [IMSoP] wrote: > > On 25/08/2024 18:44, John Bafford wrote: > >> Although I'm not sold on the idea of using default as part of an >> expression, I would argue that a default function parameter value is >> fair game to be read and manipulated by callers.

Re: [PHP-DEV] State of Generics and Collections

On Friday, 23 August 2024 at 23:55, Rob Landers wrote: > On Fri, Aug 23, 2024, at 23:06, Larry Garfield wrote: >> With generics, the syntax isn't the hard part. The hard part is type >> inference, or accepting that generic-using code will just be extraordinarily >> verbose and clumsy. There is

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 18:46, Rowan Tommins [IMSoP] wrote: On 25/08/2024 18:30, Bilge wrote: I apologise for coming on strong, but I put a lot of effort into this, so I take exception to the implication that anyone involved took the easy way out to arrive at this (our best) solution. I apologise for

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 17:05, Rowan Tommins [IMSoP] wrote: On 25/08/2024 16:29, Bilge wrote: You can write, `include(1 + 1);`, because `include()` accepts an expression. You will get: "Failed opening '2' for inclusion". Should we restrict that? No, because that's just how expressions work in any contex

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 20:46, Rowan Tommins [IMSoP] wrote: > On 25/08/2024 18:44, John Bafford wrote: > >> Although I'm not sold on the idea of using default as part of an >> expression, I would argue that a default function parameter value is >> fair game to be read and manipulated by callers

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 18:44, John Bafford wrote: Although I'm not sold on the idea of using default as part of an expression, I would argue that a default function parameter value is fair game to be read and manipulated by callers. If the default value was intended to be private, it shouldn't be in the

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 18:21, Rowan Tommins [IMSoP] wrote: > On 25/08/2024 16:54, Rob Landers wrote: > > Hi Rowan, you went through a lot of trouble to write this out, and the > > reasoning makes sense to me. However, all the nonsensical things you > > say shouldn’t be allowed are already per

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 18:30, Bilge wrote: I apologise for coming on strong, but I put a lot of effort into this, so I take exception to the implication that anyone involved took the easy way out to arrive at this (our best) solution. I apologise for the inadvertent offence. It was based solely on th

Re: [PHP-DEV] [RFC] Default expression

Hi Rowan, > On Aug 25, 2024, at 11:31, Rowan Tommins [IMSoP] wrote: > > 3) The expression should be passing additional information into the function, > not pulling information out of it. The syntax shouldn't be a way to write > obfuscated reflection, or invert data flow from callee to caller.

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 18:12, Rowan Tommins [IMSoP] wrote: For instance, rather than adding "default" to the "expr" rule in the grammar, and then restricting it at compile-time, maybe we add a new grammar rule "expr_with_default", usable only in expressions and with a very limited set of productions.

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 17:36, Ilija Tovilo wrote: I don't agree with that. Constant expressions in PHP already only support a subset of operations that expressions do. However, default is proposed to be a true expression, i.e. one that compiles to opcodes. This is circular: obviously, changing the prop

Re: [PHP-DEV] [RFC] Default expression

Hi Rowan On Sun, Aug 25, 2024 at 6:06 PM Rowan Tommins [IMSoP] wrote: > > On 25/08/2024 16:29, Bilge wrote: > > You can write, `include(1 + 1);`, because `include()` accepts an > > expression. You will get: "Failed opening '2' for inclusion". Should > > we restrict that? No, because that's just h

Re: [PHP-DEV] [RFC] Default expression

> Special-casing the T_DEFAULT grammar would not only bloat the grammar rules > but also increase the chance that new expression grammars introduced in > future, which could conveniently interoperate with `default`, would be > unintentionally excluded by omission. Forgot to add that I don't thi

Re: [PHP-DEV] [RFC] Default expression

On Aug 25 2024, at 11:31 am, Rowan Tommins [IMSoP] wrote: > > > Even then, I look at that list and see more problems than use cases. As the > RFC points out, library authors already worry about the maintenance burden of > named argument support, will they now also need to question whether some

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 16:54, Rob Landers wrote: Hi Rowan, you went through a lot of trouble to write this out, and the reasoning makes sense to me. However, all the nonsensical things you say shouldn’t be allowed are already perfectly allowed today, you just have to type a bunch of boilerplate reflecti

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 16:29, Bilge wrote: You can write, `include(1 + 1);`, because `include()` accepts an expression. You will get: "Failed opening '2' for inclusion". Should we restrict that? No, because that's just how expressions work in any context where they're allowed. I think a better compar

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 17:31, Rowan Tommins [IMSoP] wrote: > On 25/08/2024 14:35, Larry Garfield wrote: >> My other concern is the list of supported expression types. I >> understand how the implementation would naturally make all of those >> syntactically valid, but it seems many of them, i

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 15:04, John Coggeshall wrote: Other thoughts here are what happens when |default| resolves to an object or enumeration or something complex? Your original example had |CuteTheme| , so can you call a method of |default| ?? I could entirely see someone doing something like this for

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 14:35, Larry Garfield wrote: My other concern is the list of supported expression types. I understand how the implementation would naturally make all of those syntactically valid, but it seems many of them, if not most, are semantically nonsensical. I tend to agree with Larry an

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 14:35, Larry Garfield wrote: The approach here seems reasonable overall. The mental model I have from the RFC is "yoink the default value out of the function, drop it into this expression embedded in the function call, and let the chips fall where they may." Is that about accur

Re: [PHP-DEV] [RFC] Default expression

On Aug 25 2024, at 11:11 am, Rob Landers wrote: > > Which operants don’t make sense? Well certainly all of the ones toward the end of the appendix in the RFC the RFC itself notes are non-sensical. Personally, I'm not sold on the idea default should be an operand in an expression at all though.

Re: [PHP-DEV] [RFC] Decoding HTML and the Ambiguous Ampersand

> On Aug 25, 2024, at 3:15 AM, Jakob Givoni wrote: > > > On Sat, Aug 24, 2024 at 10:31 PM Dennis Snell > wrote: >> On Aug 24, 2024, at 2:56 PM, Jakob Givoni > > wrote: >>> >>> Hi Dennis, >>> >>> Overall it sounds like a reasonable R

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 16:58, John Coggeshall wrote: > > >> If the underlying API changes the argument type, consumers will have an >> issue regardless. For those cases where the expression is simply `default`, >> you'd actually be protected from the API change, which is a net benefit >> a

Re: [PHP-DEV] [RFC] Default expression

> If the underlying API changes the argument type, consumers will have an issue > regardless. For those cases where the expression is simply `default`, you'd > actually be protected from the API change, which is a net benefit already. > > This also protects the user from changes in the argument

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, 9:06 AM John Coggeshall wrote: > > > On Aug 24 2024, at 12:49 pm, Bilge wrote: > > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I > think some of you might enjoy this one. Hit me with any feedback. > > > Seems like you are missing an optio

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 15:35, Larry Garfield wrote: > On Sat, Aug 24, 2024, at 11:49 AM, Bilge wrote: > > Hi gang, > > > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I > > think some of you might enjoy this one. Hit me with any feedback. > > > > This one already comes c

Re: [PHP-DEV] [RFC] Default expression

On Aug 24 2024, at 12:49 pm, Bilge wrote: > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I > think some of you might enjoy this one. Hit me with any feedback. > Seems like you are missing an option for your theme example, which would be to simply extend the C

Re: [PHP-DEV] [RFC] Default expression

On Sat, Aug 24, 2024, at 11:49 AM, Bilge wrote: > Hi gang, > > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I > think some of you might enjoy this one. Hit me with any feedback. > > This one already comes complete with working implementation that I've > been cooking for a li

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 12:01, Bilge wrote: > On 25/08/2024 10:49, Juliette Reinders Folmer wrote: > > (resending as I accidentally originally send a private reply instead > > of sending the below to the list) > > > > On 24-8-2024 18:49, Bilge wrote: > >> Hi gang, > >> > >> New RFC just dropped

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 10:49, Juliette Reinders Folmer wrote: (resending as I accidentally originally send a private reply instead of sending the below to the list) On 24-8-2024 18:49, Bilge wrote: Hi gang, New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might e

Re: [PHP-DEV] [RFC] Default expression

(resending as I accidentally originally send a private reply instead of sending the below to the list) On 24-8-2024 18:49, Bilge wrote: Hi gang, New RFC just dropped: https://wiki.php.net/rfc/default_expression. I think some of you might enjoy this one. Hit me with any feedback. This one al

Re: [PHP-DEV] [RFC] Default expression

On 25/08/2024 04:06, Ben Ramsey wrote: Great RFC, Bilge! I was already on-board after the introduction, but if I had any doubts, the examples in the appendix sold me. Cheers, Ben Thanks, Ben. That means a lot to me :) Cheers, Bilge

Re: [PHP-DEV] [RFC] Decoding HTML and the Ambiguous Ampersand

On Sat, Aug 24, 2024 at 10:31 PM Dennis Snell wrote: > On Aug 24, 2024, at 2:56 PM, Jakob Givoni wrote: > > > Hi Dennis, > > Overall it sounds like a reasonable RFC. > > > Dennis: > > > > > Niels: > > > > > > I'm not so sure that the name "decode_html" is self-descriptive > enough, it sounds ver

Re: [PHP-DEV] [RFC] Default expression

On Sun, Aug 25, 2024, at 04:41, Mike Schinkel wrote: > > >> On Aug 24, 2024 at 5:16 PM, mailto:rob@bottled.codes>> wrote: >> I'm not sure what you mean here. I use this method all the time :) much to >> the chagrin of some of my coworkers. >> >> function stuff($foo = 'bar', $baz = 'world'); >