[PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

reciative if you could give is a second look. > All in all I do not understand the benefits of this approach compared to > Nikita’s RFC. I have moved the benefits to the beginning of the document and expanded the list I elaborate on. Hopefully they will be clear now? -Mike Schinke

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

> > Den fre. 6. sep. 2019 kl. 07.22 skrev Mike Schinkel : >> Thank you very much for your feedback. You illustrated perfectly why I >> should not have produced that proposal in haste. >> >> Your confusion was due to my first draft errors, which thanks to your &g

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

Before responding to your points let me reiterate that I made the proposal as much to generate discussion on ideas that I was not seeing discussed as to see *my* proposal get selected and implemented. So I like to think I won't be defensive about any criticism, and will be happy if the only

[PHP-DEV] Union Type (singular) straw man proposal

st.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117> Since I'm effectively new to the list this time please go easy on me? :-) Thanks in advance for all your consideration. -Mike Schinkel

Re: [PHP-DEV] [RFC] Object Initializer

> IMO should stay specific for arrays only. Why? Is there an objective reason? Is there some aspect of the syntax that makes it appropriate for arrays but inappropriate for object initialization? These are honest question. My two cents: I would like to type less too, but I have always

Re: [PHP-DEV] [RFC] Object Initializer

> On Sep 13, 2019, at 2:39 AM, Michał Brzuchalski > wrote: > $obj->foo => 123; > Simply, that's not the way you initialize object property values. So by the same logic this should be PHP's way to initialize array elements, right? $arr['foo'] => 123; But it is not. Obviously we both know that

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

-) -Mike P.S. I am not seeing much traction from this proposal so even though we discuss the nuances it seems likely it won't matter beyond this discussion. > On Sep 11, 2019, at 6:07 AM, Larry Garfield wrote: > > On Sun, Sep 8, 2019, at 2:11 PM, Mike Schinkel wrote: >> Hi Steph

Re: [PHP-DEV] Changing fundamental language behaviors

> On Sep 12, 2019, at 10:37 AM, Lynn wrote: > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler wrote: > >> There are valid reasons for not always initializing variables or array >> keys. It might be a bad >> reason in your opinion, but others view it as perfectly acceptable. >> > > I recently

Re: [PHP-DEV] Changing fundamental language behaviors

> Whenever one of these errors will occur, you can initialize either the array > key or variable with null and it will work again without changing behavior. Whatever the case, changing warnings to errors would require fixing working code. And for many people, that would requiring investing

Re: [PHP-DEV] Changing fundamental language behaviors

> How many of those are actually developers? Because the way I understand this > numbers, "powering the web", that doesn't mean 34% are also developers. It > wouldn't surprise me if a big portion of these applications could've also be > a system written in another language, deployed, plugins

Re: [PHP-DEV] Changing fundamental language behaviors

On Sep 12, 2019, at 11:06 AM, Olumide Samson wrote: > I think they could switch to using null instead, or perhaps get something > else to differentiate what they have initialized or not, Perhaps, but switching the code requires finding the right people to do the work and then funding the

Re: [PHP-DEV] Changing fundamental language behaviors

n lies. -Mike > On Sep 12, 2019, at 11:14 AM, Chase Peeler wrote: > > > > On Thu, Sep 12, 2019 at 2:10 PM Lynn <mailto:kja...@gmail.com>> wrote: > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > > > > > >

Re: [PHP-DEV] [RFC] Object Initializer

(Sorry for sending three replies to one message, but the list server said my reply was too long to send as just one. I could have made it shorter but then I would have had to omit all the example code.) @rasmus: HOWEVER, I see no reason we must pit object initializers and named parameters

Re: [PHP-DEV] [RFC] Object Initializer

> On Sep 13, 2019, at 3:18 AM, Rasmus Schultz > wrote: > > All in all, I find this feature is useful or applicable only to a few, > select patterns within the language - it isn't general enough. > ... > In my opinion, language features should be as general as possible

Re: [PHP-DEV] [RFC] Object Initializer

set. When creating an object using object initialization I think it should just bypass and only call __init(). PHP could generate an error if any required fields are not set. $customer = new Customer{ name => 'mike schinkel', email => 'm...@newclarity.net <mailto:m...@newclarity.net

Re: [PHP-DEV] [RFC] Object Initializer

> On Sep 14, 2019, at 1:50 AM, Marco Pivetta wrote: Thank you for your reply. > lazy initialisation is already possible in userland: adding more magic to the > language for a use-case that is already implemented seems problematic to me. I think I am missing something. I was not aware I was

Re: [PHP-DEV] PHP's declining(?) popularity

kage, please? And maybe go leave your comment on that blog post, instead? :-) -Mike > > > 2019.09.15 06:32 Mike Schinkel rašė: >> https://medium.com/@trungluongquang/why-python-is-popular-despite-being-super-slow-83a8320412a9 >> 1. End-users just don’t care (about slowe

Re: [PHP-DEV] Features related to Object Initializers

2 of 2 > On Sep 16, 2019, at 6:22 AM, Rowan Tommins wrote: > > I don't particularly see them as a "group". If I write foo($a, 42), I don't > think of $a and 42 being bound together in any way; each is passed as a > value to one variable in the function. So that's my answer to "why not"; >

Re: [PHP-DEV] Features related to Object Initializers

I had to snip context and split in two to get under the 30k char limit. > On Sep 16, 2019, at 6:22 AM, Rowan Tommins > wrote: > > Points 1 and 3 are solved by anonymous classes, which we already have. > Point 2 is a bit vague; is your point essentially "if we

[PHP-DEV] PHP's declining(?) popularity

> On Sep 14, 2019, at 5:18 PM, Olumide Samson wrote: > > https://jaxenter.com/php-tiobe-sept-2019-162096.html > I think this is one of those things we get from voting no... > > I might be wrong anyways :-? If those specific rankings are legitimately a cause for concern then it would make

Re: [PHP-DEV] Defining the PHP Group

> > On Sep 15, 2019 at 8:57 AM,wrote: > > Anyone may initiate an RFC for any subject. > For example, this phrasing means the RFC system itself can be put up to vote, to be removed and replaced with something entirely non-democratic. I do not want dive too deep into this

Re: [PHP-DEV] Features related to Object Initializers

> On Sep 16, 2019, at 6:20 PM, Larry Garfield wrote: > > I think everyone's in agreement about: > > 1) Making objects easier to work with. > 2) Devs should use objects more. I am glad we are reaching some common ground. :-) > (Side note: I have an article submitted to php[architect] entitled

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

Hi Nikita, I am really happy to read your email. As you may have noticed I recently started participating on this list. About that time I tried to get PHP compiled and working locally, and I failed miserably. I decided I would participate on the list for a while and maybe after some time I

[PHP-DEV] The RFC discussion process?

Hi all, I am relatively new to discussions on the list, and so I have tried to understand the ethos of the community to stay within bounds that the community generally considers acceptable. However I am realizing those the bound of acceptability may be fluid at times so I am asking

[PHP-DEV] Features related to Object Initializers

> On Sep 14, 2019, at 4:47 PM, Rowan Tommins wrote: > I think that's only true because you've actually proposed a number of related > but different features. See my other email to the list asking about what is in-bounds and what it out-of-bounds regarding RFC discussion. I seemed logical to

Re: [PHP-DEV] The RFC discussion process?

was submitted based on reading other people's comments on other RFCs. -Mike > > On Sep 16, 2019 at 2:00 AM, mailto:kont...@beberlei.de)> > wrote: > > > > Hello Mike, > > On Mon, Sep 16, 2019 at 3:50 AM Mike Schinkel > wrote:

Re: [PHP-DEV] The RFC discussion process?

> On Sep 16, 2019, at 4:10 AM, Arnold Daniels > wrote: > > [Arnold Daniels - Chat @ > Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=5wb22) > [5wb22] > > On September 16, 2019 at 7:40 GMT, Mike Schinkel wrote: > >>>

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

Hi Stephen, Thank you for the follow up. I am heading out for a week-long conference later today and not sure if I will have time to participate on the list for a while so I wanted to get a quick reply to you before I leave. > In terms of how I would see it working - In hindsight I should

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

Hi Stephen, Thanks again. > So let me start out by clarifying that what *I* was suggesting with unions is > quite a different concept than you’re talking about. I did not realize you were proposing a different solution, too. Sorry I missed that. > yes, I’m aware there’s potential ambiguous

[PHP-DEV] Syntax Sugar (was [PHP-DEV] [RFC] Reclassifying engine warnings)

> One thing I like PHP for is a distinct lack of huge amounts of syntax > sugar. Take Ruby - it's a hell to read the code. I think it is unfair to reference Ruby's capabilities as a counter-example for syntax sugar. The Ruby language allows developers to create what are effectively new

Re: [PHP-DEV] [RFC] Object Initializer

Hi Michal, > https://wiki.php.net/rfc/object-initializer I recently joined this list again after many years away, and a primary reason was to eventually propose an RFC that is almost exactly what you are calling Object Initializers. So a huge thumbs up on this RFC. Kudos. I wish I had a

Re: [PHP-DEV] [RFC] Object Initializer

> What's the added benefit of this compared to implementing a constructor? Michal my have a different answer but my answer are the following two benefits plus a 3rd related benefit: 1. The ability to add strictness to object initialization vs. using arrays of properties. PHP itself could flag

Re: [PHP-DEV] [RFC] Object Initializer

> That said, I generally use arrays rather than DTO objects I too have often used arrays. But then I have always been rigorous to ensure that variables and array elements are initialized before use, and fortunately I do not have a lot of typos in code I write. However I recently took on a

Re: [PHP-DEV] Changing fundamental language behaviors

> Many of these are ticking bombs - unmaintained extensions with possible > security issues. Totally agree. > Right now the biggest problem of WordPress ecosystem is quality of community > extensions and themes. Being intimately involved in the WordPress ecosystem, I do not know If it is the

Re: [PHP-DEV] [RFC] Object Initializer

Arnold, > This can easily be done in a number of ways, like the suggested helper > function. A helper function can simulate an object initializer but it cannot provide the same potential benefits. The helper function uses array keys to identify properties, and as array keys cannot be

Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)

On Sep 18, 2019, at 8:29 PM, Bishop Bettini wrote: > would you be willing to transfer your knowledge to our documentation? Absolutely! And thank you. I am traveling this week so I can't start until next week, but email me off list and we can coordinate? -Mike

Re: [PHP-DEV] GitHub RFC workflow

> https://www.vice.com/en_us/article/9kevn7/spain-and-github-are-blocking-an-app-that-helped-protesters-organize > https://github.com/github/gov-takedowns/blob/master/Spain/2019/2019-10-26-GuardiaCivil.md It would seem to me that if any country decided that downloading and working with PHP were

Re: [PHP-DEV] GitHub RFC workflow

> All are real problems, today. Spain's exams is the smallest one. Other cases > affect many people already with Github (at large). You misunderstood my comments. I did not mean they were not real problems for the people who they affected by those issues; they absolutely are. And I have

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 17, 2019, at 2:27 PM, Rowan Tommins wrote: > Well, pretty much any method that returns array *could* be called "to array", > but not many would be good candidates for such a generic name. You might > return an array structure to be incorporated into a JSON response, or to be > passed

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 17, 2019, at 6:51 PM, Rowan Tommins wrote: > > I'm not sure avoiding the name "toArray" necessarily leads to "really long > method names" - even with extremely specific distinctions, you don't need to > call the method "toJsonArrayForVersion5OfTheApi", just "toV5Json" or >

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 17, 2019, at 9:41 AM, Aimeos | Norbert Sendetzky > wrote: > > Since PHP 7.1 there's the "iterable" pseudo type hint that matches > "array" and "Traversable". > > PHP frameworks would profit from support of an "arrayable" pseudo type > hint that matches "array" and all objects that

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 18, 2019, at 5:53 AM, Rowan Tommins wrote: > > On Mon, 18 Nov 2019 at 00:18, Mike Schinkel wrote: >> Even if short, a code base littered with method names like toV5Json() or >> getV5Array() or formatForJsonV5() is still inconsistent. > > Inconsiste

[PHP-DEV] Enabling ArrayObject et.al. to fully replace array usage

I decided to create a new thread since I was diverging the topic. > On Nov 18, 2019, at 5:36 AM, Michał Brzuchalski > wrote: > Currently, arrays all together with rest of scalar types are value-types > which means when they're passed on (unless passed by a reference) their > copies are

Re: [PHP-DEV] Inconsistent class behavior and undocumented(?) BC change

Hi Larry, > I am not clear on why __construct() is special in this case; I believe that is the Liskok substitution principle at work, and that fact the principle does not apply to constructors. For reference: - https://softwareengineering.stackexchange.com/a/302477/9114 -

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

> On Oct 27, 2019, at 7:04 PM, Rowan Tommins wrote: Thank you for your comments. > I chose the phrase "static analysis tool" deliberately, because I wanted to > think about the minimum requirements for such a tool, rather than its > long-term possibilities. Your points are all

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

> On Oct 27, 2019, at 11:20 PM, Mark Randall wrote: > > On 27/10/2019 23:56, Mike Schinkel wrote: >> 2. Allowing PHP to continue to meet the needs of new/less-skilled >> programmers and/or people who want a more productive language for smaller >> projects t

Re: [PHP-DEV] Inline switch as alternative to nested inline conditional

> On Oct 16, 2019, at 5:21 PM, Bob Weinand wrote: > what's the concrete advantage of this syntax as opposed to the already > possible: > > $value = [ > A1 => A2, > B1 => B2, > ][expr()] ?? C; Speaking specifically to your example, it does not handle multiple cases. IOW, you cannot do this:

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

Hi Kosit, Thank you for your reply. > On Oct 20, 2019, at 3:54 AM, Kosit Supanyo wrote: > > Hi Mike > > Is there a strong reason to change to using fat arrows and colons? > > The reason is statement/expression semantic. Okay, so you chose commas and fat arrows because of perceived

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

> On Oct 20, 2019, at 7:08 PM, Kosit Supanyo wrote: > > Yes because they are statements, that's the point which I've stated many > times. And I am suggesting that a block-enclose expression should not be limited to expressions only, but instead be able to use statements in the future. Using

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

> On Oct 20, 2019, at 7:59 AM, Rowan Tommins wrote: > On 19/10/2019 17:40, Kosit Supanyo wrote: >> Like function declaration and function expression in JavaScript, if >> `switch` appears as first token at statement level it will be recognized as >> statement but if `switch` is in expression

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

> On Oct 20, 2019, at 7:28 AM, Rowan Tommins wrote: > On 20/10/2019 01:39, Mike Schinkel wrote: >> Not yet having experience working on PHP's parser I do not know how it is >> configured nor what about the design of PHP requires keywords unable to be >> used as constant

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

> On Oct 21, 2019, at 4:51 AM, Rowan Tommins wrote: > > On Sun, 20 Oct 2019 at 22:35, Mike Schinkel wrote: >> I would much prefer to use a switch for multiple, mutually exclusive cases >> no matter what how complex the expression is because with a switch the >>

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

> On Oct 21, 2019, at 11:12 AM, Rowan Tommins wrote: >> What if in the future PHP implements variadic syntax for assigning to >> arrays, e.g. $var = 1,2,3 where $var could satisfy a $variadic parameter >> set of parameters w/o requiring `...`? If PHP embraces that — note GoLang >> has something

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

> On Oct 20, 2019, at 11:11 PM, Kosit Supanyo wrote: > Ok, so let's look at a scenario. Will we be able to do this in the future, if > we decide to allow multiple expressions to result in a final value? > $y = switch ($x) { > case 1 => $arr = get_array(), array_pop($arr), > case -1 =>

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

> On Oct 21, 2019, at 4:38 PM, Benjamin Morel wrote: > Sure, you can do without exceptions. I think what you're suggesting is > similar to Go's error handling. Yes, it is like Go's error handling. > But PHP at some point decided in favour of > exceptions, so it would be logical to pursue in

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

> On Oct 21, 2019, at 5:10 AM, David Negrier > wrote: > > Hey list, > > TL;DR: > > 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. JMTCW, which is an opinion admittedly

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

> On Oct 24, 2019, at 8:05 AM, Dik Takken wrote: > I fully agree. However I think the fear of having to add tons of try / > catch to existing code is exaggerated. I use Python a lot, which > quite an exception throwing machine in comparison. Still, my code is not > cluttered with exception

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

> On Oct 24, 2019, at 12:31 PM, Rowan Tommins wrote: > > On Thu, 24 Oct 2019 at 16:38, Mike Schinkel wrote: > >>> Here, try() would swallow only FileException, other exceptions are still >>> thrown. I'm not sure if this construct is worth introducing thoug

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

> On Oct 24, 2019, at 8:50 AM, Dik Takken wrote: > However, you could also choose to leverage the new behavior of throwing > exceptions to simplify your code. Passing the error condition to the > caller can now be done by *not* handling the exception that is thrown, so: > > $filepath = __DIR__

Re: [PHP-DEV] [RFC] anti-coalescing-operator

> On Oct 24, 2019, at 6:49 PM, Ken Stanley wrote: > I would be keen to see the more expressive techniques that retain the > succinctness of having a not-null coalescing operator. When I read your first example, I immediately thought I would handle your example in this way: $user->setFName(

Re: [PHP-DEV] [RFC] anti-coalescing-operator

> On Oct 24, 2019, at 8:03 PM, Andreas Hennings wrote: > > On Fri, 25 Oct 2019 at 01:28, Sara Golemon wrote: >> >> https://wiki.php.net/rfc/nullsafe_calls > > ?-> is a great idea. Totally agree, that would be nice. > The problem is this only works for method chaining, not for function >

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

> On Oct 28, 2019, at 6:00 AM, Rowan Tommins wrote: > > Current tools tend to actually work on a directory level, because you don't > actually know what namespaces are involved until after you've loaded it, > and a file can include code for two completely separate namespaces. My > thinking was

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

> On Oct 29, 2019, at 5:49 PM, Rowan Tommins wrote: > > I think the problem is that as soon as you have two engines targeting > different feature sets, it will be hard to persuade people to spend equal > attention on both. If all the new features end up being added to one engine, > the other

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

> On Oct 17, 2019, at 11:14 PM, Bishop Bettini wrote: > > +1. It's 100% opt-in. People can keep using implicit fall-through, their own > /* fallthrough */ comments, or the new token. There's virtually no overhead > in the compile phase and it doesn't mess with the jump table optimizations. >

Re: [PHP-DEV] Inline switch as alternative to nested inline conditional

> On Oct 15, 2019, at 11:33 PM, Michał Brzuchalski > wrote: > > I have an RFC in draft for that and planning to finish it soon together > with some syntax optimisations - you can see it at > https://wiki.php.net/rfc/switch-expression-and-statement-improvement > > Cheers, > Michał Brzuchalski

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

> On Oct 18, 2019, at 4:45 AM, Markus Fischer wrote: > > On 18.10.19 00:07, Mike Schinkel wrote: >>case 'educationtype': >> $update = false; >> fallthrough; > > I was about to suggest `continue`, alas we know that would clash :-) > > Sugg

Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator demo

> On Oct 19, 2019, at 12:40 PM, Kosit Supanyo wrote: > > Hi Internals > > I've just finished an implementation of 'switch-expression' that have been > discussed recently. So I would like to present my ideas here. This is great to see that you proactively implemented this. > The basic syntax

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

> On Oct 19, 2019, at 3:21 AM, Kris Craig wrote: > If we're going to do this, let's take the opportunity to make it even more > useful. Assuming this idea truly does have momentum, I hope we do not get so focused on the `perfect` that we postpone the `good` indefinitely. There is always next

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

> On Oct 19, 2019, at 3:05 AM, A.L.E.C wrote: > Imo, this would make more sense if fallthrough did something more, e.g. > allowing > > case X: > if (something) { > fallthrough; >} > something-else; > break; > case Y: Interesting. What would you

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

> On Oct 20, 2019, at 3:01 AM, A.L.E.C wrote: >>> It might be not useful enough to justify a BC break. > > That was my intention, to find more value in a new feature to justify BC > break. Your point was well taken, which is why I am now suggesting we consider (one of) the following instead

[PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

Hi All, Before creating an RFC I wanted to get reactions to the idea of adding FALLTHROUGH option to SWITCH/CASE for when the developer explicitly want logic to fall through to the next case and does not want to use a BREAK. My simples motivation for this feature is that my IDE (PhpStorm)

Re: [PHP-DEV] Re: Adding explicit intent for SWITCH/CASE fall through?

> On Oct 17, 2019, at 5:42 PM, Mark Randall wrote: > > On 17/10/2019 21:54, Mike Schinkel wrote: >> Additionally it could be added in 8.0 and then in 8.1 flagged with a warning >> when a CASE does not have one for the two, but only if people don't object >> to this. Whil

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

Hello all: While reading the [RFC] Union Types v2 thread and comments from Dmitry[1], and especially Benjamin[2] who suggested "building a static analysis tool which could prove that certain type checks would never fail, and prime OpCache" it occurred to me that a PHP pre-compiler could

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 19, 2019, at 10:54 AM, Rowan Tommins wrote: > Neither. We should discuss the advantages of the feature, the potential > costs, and whether other features would be even better. In concept, I agree. But AFAIK no other "better" features were proposed. Do you have an alternate to

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

> On Nov 26, 2019, at 11:27 AM, Ian Littman wrote: > > You're right that turning off eval() isn't a silver bullet, and if you can > get external code running on someone's box there are a lot worse things you > can do. > > On Tue, Nov 26, 2019 at 10:11 AM Benjamin Morel > wrote: > >> Hi Ian,

Re: [PHP-DEV] Internals "camps"

> I'm not sure where's the log jam here? The issue is not this specific RFC. As I wrote earlier, there appear to be heated and non-stop debates over (at least) BC, and possibly other areas. People dig in on a position and then won't consider any other options that might be available. > It's

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

My, my this is a heated topic. I am commenting in part because I do not have a dog in this hunt. I am okay leaving it, I am okay if it is deprecated. There are other things for PHP that I care far more about than this RFC. So... I am wondering if everyone participating in this discussion

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

> On Oct 8, 2019, at 4:29 PM, Lynn wrote: > My middle ground is a vote, regardless of outcome. If a vote is the middle ground then why the need to participate in any discussion? Also, how is a vote a middle ground? A vote ensures that one sides wins and the other side looses. IOW, a zero-sum

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

> More generally, people take time in understanding the peculiarities of that > uncommon feature which is the backtick operator. This is a real cost. Is this a generally agreed-principle that the PHP community believes is important? If so, shouldn't we quantify what the cost is and who would

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

> a middle ground about/with silliness? there is none, for people in their > right mind; should people really find/force > themselves into conciliation about non-sense? I don't think so and mostly; I > have no say about deprecating that; > but is that a priority? does it harm anyone? someone

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

> On Oct 8, 2019, at 5:34 PM, Zeev Suraski wrote: > So while I sympathize with the effort to find a compromise - encouraging more > of these contentious proposals (by accommodating them at some level) is not > the way. Ok, but... > The real middle ground is to go for some form of opt-in

Re: [PHP-DEV] Internals "camps"

> On Oct 9, 2019, at 12:58 PM, Larry Garfield wrote: > And developing such guidelines absolutely positively cannot happen on a > public asynchronous mailing list. I've been through such processes enough > times to know that is the worst possible way to do it. When I first saw this email I

[PHP-DEV] Alternatives to the current dysfunction?

> On Oct 9, 2019, at 3:50 AM, Zeev Suraski wrote: > On Wed, 9 Oct 2019 at 0:38 Mike Schinkel <mailto:m...@newclarity.net>> wrote: > ...it seems you have identified at least one way to seek compromise. Why not > move forward with this, in general? > I did - quite

[PHP-DEV] Constraints and userland@

> On Oct 9, 2019, at 4:25 AM, Lynn wrote: > There is no middle ground in an RFC that proposes the deprecation at this > level of specifics. You either deprecate it, or you don't. The only middle > ground you can reach, is that you give it a vote to see if it should indeed > be deprecated.

[PHP-DEV] "Fighting about analogies"

> On Oct 11, 2019, at 1:44 PM, Larry Garfield wrote: > > Could y'all please go fight about analogies in another thread, rather than > one that was explicitly trying to get away from that silliness? Much obliged. Done! :-) > On Oct 10, 2019, at 1:03 PM, Chase Peeler wrote: > > Mike - I

Re: [PHP-DEV] [RFC]

> On Feb 11, 2020, at 6:13 AM, Manuel Canga wrote: > > Hi internals, > I Would like to present a possible new "::func resolution" for your > consideration. > > In first place, PHP now support "::class" in this way: > > use My\I18N; > > $mapped_array = array_map([I18N::class, 'translate'],

Re: [PHP-DEV] [RFC]

> On Feb 11, 2020, at 9:51 AM, Chase Peeler wrote: > > Can anyone thing of a use-case where you would want a string name of a > function and a callable would not be acceptable, besides possibly debugging > code that said 'echo "I'm calling ".myfunction::function;'? Everything that > I can think

Re: [PHP-DEV] [RFC]

> On Feb 12, 2020, at 2:12 AM, Guilliam Xavier > wrote: > > On Wed, Feb 12, 2020 at 4:58 AM Mike Schinkel wrote: >> >> Or best would be to add ::nameof for functions, method, classes, interfaces >> and traits > > One problem is how would `x::name

Re: [PHP-DEV] [RFC]

> On Feb 13, 2020, at 2:33 AM, Rowan Tommins wrote: > > On 13 February 2020 03:33:32 GMT+00:00, Mike Schinkel > wrote: >>> On Feb 12, 2020, at 5:47 PM, Rowan Tommins >> wrote: >>> >>> On 12/02/2020 03:58, Mike Schinkel wrote: >>>> Ret

Re: [PHP-DEV] [RFC]

> On Feb 12, 2020, at 1:40 PM, Manuel Canga wrote: > IMO, we should limit RFC to '::function'( scope and accept/reject ). Agreed. > After this, other RFC can be added/checked like Short closures( of Michal ) > or other purposes with other variation like :interface and ::trait: ( of Mike > )

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

> On Feb 12, 2020, at 1:20 PM, Niklas Keller wrote: > I think the request / response API is entirely fine being solved in > userland instead of in php-src. I want to disagree in support of this RFC. While is *has* been solved in userland, but it has been solved 25+ times in 25+ different

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

> On Feb 12, 2020, at 7:47 AM, Paul M. Jones wrote: > > That is essentially what it does now; the difference is that you mimic the > $GLOBALS array at construction time, and the instance locks automatically: > >$request = new ServerRequest([ >'_GET' => ['foo' => 'bar'], >

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

> On Feb 13, 2020, at 1:34 PM, Paul M. Jones wrote: > > Hi Mike, > > Thanks for your continued evaluation of the RFC. > >> Take a look at WordPress. It does a lot of "fixup" to $_SERVER` variables — >> to deal with badly implemented web servers — to ensure all known variables >> have a

Re: [PHP-DEV] [RFC]

> On Feb 13, 2020, at 12:26 PM, Rowan Tommins wrote: > Right, I'm with you now. However, I think the answer people are suggesting > to "how do we get the name string?" is "why do we need to?" 1. Say I want to provide users with the ability to build queries and use functions where I want to

Re: [PHP-DEV] [RFC]

> On Feb 13, 2020, at 1:48 PM, Larry Garfield wrote: >> But since I seem to be in the minority of caring about the name, let me >> propose the following which was influenced by Larry Garfield's most >> recent post. Since it seems that people want the convenience of a >> short notation to get

Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties

> On Feb 23, 2020, at 12:06 PM, Larry Garfield wrote: > > On Sun, Feb 23, 2020, at 2:39 AM, Mike Schinkel wrote: >>> On Feb 21, 2020, at 6:17 PM, Larry Garfield wrote: >>> I'm totally on board for better value object support, so that's a good >>> motive for

Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties

> On Feb 24, 2020, at 8:55 AM, Rowan Tommins wrote: > > As with typed properties, I wonder if there's a way we can introduce Now you are talking! This gives me hope after my dejected last comment on the list. -Mike -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] SimpleXMLIterator

Well, that did not work as intended... > On Feb 28, 2020, at 2:57 PM, Mike Schinkel wrote: > > OFFLIST > > First one want to say but thanks and kudos for all you are doing for PHP. > > Second, and so as not to hijack your thread or worse start a whole bike > sheddi

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

> On Feb 26, 2020, at 1:55 PM, Rowan Tommins wrote: > > On Wed, 26 Feb 2020 at 16:42, Paul M. Jones wrote: > >> Your presumption is correct! And your point on trying for better names is >> well-taken -- though I think these are "expected" names, based on my >> research into existing

Re: [PHP-DEV] Re: [RFC] Userspace operator overloading

> On Mar 2, 2020, at 9:30 AM, Nikita Popov wrote: > > On Thu, Feb 27, 2020 at 9:43 PM wrote: > >> I have changed the proposed names for the bitshift handlers to '__lshift' >> and '__rshift' (instead of __sl and __sr) to make more clear what operator >> is handled by the method (also the method

  1   2   3   4   5   >