Re: [PHP-DEV] [RFC] PHP.net analytics

> As the person that will end up having to maintain this, I wasn't aware > that https://github.com/matomo-org/matomo-php-tracker is pretty much the > same as the JS tracker. And as it does HTTPS requests from the PHP > application to Matomo, instead of a JS tracker, this seems like a > better solut

Re: [PHP-DEV] [RFC][Vote] Policy on third party code

On Nov 11 2024, at 12:03 am, Larry Garfield wrote: > > First off, the obligatory "it was open for discussion for a month, and now > you mention this?" I apologize for that, wasn't intentional. Unfortunately a whole pile of personal matters landed on my head between ... let's say October and N

Re: [PHP-DEV] [RFC][Vote] Policy on third party code

blems.. All of this is wildly inconsistent is my point. Also what happens if I decide to use a composer package component that's really a part of Laravel or Symfony or ? Is that allowed or not? I wouldn't have even blinked on a "yes" vote here if the RFC was to allow composer.. it's this other half-baked stuff that I am balking at... I'd very much like to see this RFC stripped of those bits if possible. John

Re: [PHP-DEV] [RFC][Vote] Policy on third party code

I also voted against because I think it's silly to create these arbitrary rules on the various frameworks. "Not playing favorites" is literally as easy as saying "The people who volunteered their time to build X did so using Y because that's what they knew, it doesn't mean the PHP project favors

Re: [PHP-DEV] [Discuss] Impact of E.O 14071 on PHP

Here's an article from a trusted source about it in a little more detail as well. https://www.zdnet.com/article/why-remove-russian-maintainers-of-linux-kernel-heres-what-torvalds-says/ "While this action has removed these maintainers from their official roles, it does not bar them entirely from

Re: [PHP-DEV] [RFC] Policy on 3rd party code

> So banning "full" frameworks is my attempt at steering clear of the > appearance of that kind of favoritism. Showing favoritism for Composer or > Xdebug is, well, there's no competition to complain. PHPUnit is technically > not the only testing framework on the market, but it has north of 90%

Re: [PHP-DEV] Protected destructors

nually. The engine should automatically handle calling parent destructors when necessary. If there really is some logic in the destructor that a user of a class might legitimately want to use, then that should be exposed in a separate method (with a more appropriate name, and an implementation that handles that it might be called more than once) and have the destructor call that method. -John

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

On Sep 6 2024, at 2:07 pm, Claude Pache wrote: > > > > Le 5 sept. 2024 à 18:03, John Coggeshall a écrit : > > > > > As per my previous email to the list, I have now created the official RFC > > > to deprecate calling json_serialize()

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> So if we had a #[NotSerializable] attribute (which I agree might be a good > idea) it would be implemented by setting the ZEND_ACC_NOT_SERIALIZABLE flag > on a class definition, and if this RFC passes, it would automatically apply > to json_encode() as well as serialize(). > My mistake, I hav

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> As per my previous email to the list, I have now created the official RFC to > deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. I would suggest we take a step back from this and look at it with a bit more of a wider lens. It seems to me that

Re: [PHP-DEV] Local constants

For example, if I set a temporary variable to something, and then later in the function, reuse that same name for a new temporary but don't set the value on all flow paths, then the value from earlier in the function leaks through, whereas either using a constant, or a second explicit variable definition would have exposed and/or prevented the issue. -John

Re: [PHP-DEV] Local constants

to do it without requiring docblocks. The language providing tools for being more explicit about intent in code is never bad. -John

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

One thought re-reading the RFC. abstract class Theme { public function bar(); } class CuteTheme extends Theme { public function foo(); } class Config { public function __construct(Theme $theme = new CuteTheme()) {} } $a = new Config(default->foo()); In the proposed (updated) RFC would this be p

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

On Aug 28 2024, at 9:34 am, Larry Garfield wrote: > > I don't think I'd support a list of "popular" frameworks, but mentioning > Composer, Xdebug, and PHPUnit seems a requirement for a useful modern > tutorial. Can you explain your position more here, what exactly is your concern (if I captu

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

> I agree with this to a point. What if I want my newish framework listed on > the page? What are the qualifications for being listed (or unlisted) there? > Can anyone add their own framework? Personally I say put the top 5 by Github stars on a page by themselves, and have a secondary page rank

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

> And that is how you will find that the "new" languages will "win". If we > don't promote how modern PHP Development works, then there will be more > "PHP, a fractal of bad design" articles to come for decades. > > We *must* do better than this. It probably doesn't all need to be in the > documen

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

to json_encode(). It's the default value of the first parameter to gettype(). Which would probably fail, since gettype()'s first parameter doesn't have a default. I suppose this could be solved by specifying an offset or label (e.g. as with `continue 2` in a nested loop), but that would just make it even harder to read. -John

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

On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney wrote: > You'll likely identify the increased delay in such cases. Generally speaking > these sorts of default values don't change a ton, but it's not unlikely that > you may say "I'd like half that delay" or "twice that delay". But a better

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

On Aug 26 2024, at 5:57 pm, Bilge wrote: > In case it matters, my initial inclination was also to do what some others > have suggested, and modify the SEND opcodes so that the default is not > actually looked up using reflection at all, but rather we just send nothing > to the function and it

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

On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney wrote: > > I can see a few others: > > - string concatenation. I might want to prepend or append a string to a > default. > > - fractional or multiplicative application, e.g. for durations/timeouts. > These might require testing for non-zero

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

On Aug 26 2024, at 2:39 pm, Bilge wrote: > > I like this approach. I'm still not sure I'd want to pursue adding > exclusions, but if we can identify something that's obviously bad and/or > dangerous then we can consider that short list for exclusion. That is much > more compelling than starti

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

> From the example you gave it appears that we can have a concrete problem when: > 1. There is a parameter with a default value, > 2. That parameter is type-hinted, > 3. The hinted type is declared as a union type, > 4. An earlier version of the library initialized the default with a value > havi

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

his point if some downstream caller decided to use my default value directly or not. You can argue if this is a good API design or not, but it was only written to provide a real example of how pulling the default value higher up the call chain and allowing it to be used in expressions is problematic

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] [RFC] Default expression

() is a valid expression in this context or a good idea for the language. The use of this proposed default keyword must have guardrails IMO. I think my definition above is a pretty reasonable attempt at capturing where I think the line is here and hopefully that helps guide this discussion. John

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

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

g the library, and want to support both versions, you might both not want to set the value, and yet also care what the default value is from the standpoint of knowing what to expect out of the function. -John

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

t of them out for now. To me, that basically means "default with bitwise expression support" based on what I've seen so far. John

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 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] [Concept] Flip relative function lookup order (global, then local)

On Aug 23 2024, at 3:41 pm, Rowan Tommins [IMSoP] wrote: > > None of these seem like showstoppers to me, but since we can so easily go one > step further to "global only", and avoid them, why wouldn't we? FWIW I'd support global only, specifically because of the point I wouldn't necessarily w

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

On Aug 23 2024, at 1:46 pm, Stephen Reay wrote: > > > The claims about "security" because a function you defined (or included via a > package) is resolved in place of a global one are irrelevant. If you're > including compromised code in your project, all bets are off. I have plenty of experie

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

> 1. People who don't think BC is a problem, and would like to drop > either the global or local lookup entirely, requiring disambiguation. > There is also an option of swapping the priority, making local lookups secondary to global lookups -- and to override that behavior you would require dis

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

> What do you mean by this? What is "the right thing"? Also, faster code vs. slower code by default is "the right thing" too.

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

On Aug 23 2024, at 12:35 pm, Stephen Reay wrote: > > > would find it non-sensical that you must add a backslash for the engine to > > do the "right thing" (in this case, optimize their code with a security > > benefit), vs just doing the right thing by default. > > What do you mean by this? Wh

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

On Aug 23 2024, at 12:27 pm, Stephen Reay wrote: > > The current inconsistencies between symbol types can be avoided in userland > in a 100% consistent way. Import or qualify the symbols you use, all the > time, and you have 0 inconsistencies or bizarreness in terms of what it used > when. S

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

On Aug 23 2024, at 11:49 am, Rowan Tommins [IMSoP] wrote: > > And most users don't object to using a leading backslash, they just (quite > reasonably) have no idea what impact it has on the ability of the engine to > optimise their code. I think this is a misread, and I don't think you can ar

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

garding the subject at hand I've made my case here and we can agree to disagree -- changing the function lookup order is an easy win with security benefits and, according to Ilija, performance benefits. I think it should be seriously considered. John

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

Forgive me, s/Illija/you :)

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

make it easier to perform such an attack, which as Illija pointed out is actually making PHP slower, in the name of backward compatibility? Defense in depth is a cornerstone of application security. John

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

ackages should be FQing their internal function calls. The natural behavior of the language shouldn't be the insecure way of doing things for the sake of maintaining BC compatibility with existing, insecure, code. Cheers, John

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

On Aug 2 2024, at 4:37 pm, Bilge wrote: > My only concern is there needs to be an alternative way to do this: > intercepting internal calls. Sometimes, whether due to poor architecture or > otherwise, we just need to be able to replace an internal function call. One > example I can think of r

Re: [PHP-DEV] String enums & __toString()

ring() , would anyone have a strong objection to getting an RFC going to get this voted on? I didn't look closely at the original PR from the "auto implement __toString()" for string-backed enums, but I think this might literally be a one-liner just to enable enums to implement __toString() and the rest can be tossed. John

Re: [PHP-DEV] String enums & __toString()

On Aug 16 2024, at 6:49 pm, Rob Landers wrote: > > That being said, I would like to be able to use | and & on integer enums more > than I would strings as stringables. Something like “flags” mode in C#. Maybe > even make “flag” a backing type of enums. It would make a ton of json flags > much

Re: [PHP-DEV] String enums & __toString()

nse for it to ever return anything but that string constant. I don't think this is something ADTs or tagged unions or anything of the sort should play a role in deciding. John

Re: [PHP-DEV] String enums & __toString()

> Didja really? > > https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums I swear I did. That said, looking at that RFC it's a slightly different take than what I am suggesting. This RFC suggests that string enums automatically implement Stringable . I am pointing out that i

[PHP-DEV] String enums & __toString()

t we can look at correcting? John

Re: [PHP-DEV] [DISCUSSION] Class Constant Enums?

} private init() {} } let parent = Parent() //'Parent' initializer is inaccessible due to 'private' protection level let child = Parent.Child() //ok ``` Swift also has a fileprivate visibility, so the same could be accomplished with a fileprivate init on Parent with a non-nested Child in the same file. -John

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Aug 14 2024, at 5:27 pm, Lanre wrote: > > Can you point out where either of us suggested writing PHP in another > language? You might be mixing this up with the C11 thread, which has nothing > to do with this. All I'm proposing is improving the current C++ support in > the engine. > https

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

Friend, honest to god you are really not doing yourself any favors here. You came on this list with a proposal. I think it's a bad idea, and I've enumerated the reasons why I have come to that conclusion: If it's so easy and transparent to improve support for C++, it could easily exist outside o

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

lol. Listen friend, I've been involved in PHP internals on and off for over 20 years -- and so has Pierre. You'd do well to respond with a little more consideration instead of flying off the handle calling us ignorant rust developers lol. The idea of enhancing support for C++ makes no sense. It

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

On Aug 12 2024, at 12:27 pm, Lanre wrote: > > > On Mon, Aug 12, 2024 at 9:58 AM John Coggeshall (mailto:j...@coggeshall.org)> wrote: > > > > > > I’m considering adding some C++ enhancements to the Zend API. > > I would definitely like to see an RFC for this

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

> > I’m considering adding some C++ enhancements to the Zend API. I would definitely like to see an RFC for this if it was to be considered. To me, adding a whole new way of doing things internally without completely removing the old way is just asking for a more brittle, potentially less secur

Re: [PHP-DEV] [RFC]I'd like to see the RFCs that deprecate the FFI non-static approach start voting

ke to improve the situation, so it seems like any well thought out proposal would likely succeed. Unless of course I'm grossly underestimating the popularity of FFI today.. in which case perhaps I should take my thoughts to the docs mailing list.. John

Re: [PHP-DEV] [Early Feedback] Pattern matching

ld development. But since it'd be entirely new and opt-in types, there's no direct BC concerns, and maybe some of the typechecking perf hit when you validate inserts/updates could be elided by the optimizer in the presence of typehints. (e.g. you have an Array and you insert a value the compiler or optimizer can prove is an int, you don't need to do a runtime type check.) There'd also probably have to be something done to maintain the COW semantics that array has without having to have explicit clone operations. -John

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

On Jun 7 2024, at 8:49 pm, Erick de Azevedo Lima wrote: > The new keyword is meaningful and everyone knows what's being done just by > looking at it. Removing it would make the language less readable. But it's a > BC so big that I don't think it can be done anyway. > > FWIW Languages like Da

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

> So here is my proposal : > > Add a "new" shorthand, using the tilde character : "~" -10. Please, don't make PHP as unreadable as Perl. IMO It's two extra characters at worst and would be solved much more elegantly by removing the new keyword entirely. J

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

w keyword go away as well, but as long as functions and classes are in separate namespaces, that might be difficult. -John

Re: [PHP-DEV] Requiring GPG Commit Signing

"verified". Command > line GIT doesn't either, just: > That's really unfortunate (why even bother). IMO without some sort of web of trust verification process for GPG, this just feels like added barriers for no actual win. In fact, if anything I think it's more likely to give the project a false sense of security. Cheers, John

Re: [PHP-DEV] Requiring GPG Commit Signing

conferences to do key signings of their GPG keys, I question exactly what this buys the project other than an illusion of security and additional complexity? I couldn't even really trust Derick to read me his GPG public key character-by-character over the phone now days thanks to AI. Just Sayin' John

Re: [PHP-DEV] is this thing on?

> As one of those relics of the past, I'll say that there are plenty of people, myself included, who stay subscribed to this list to keep an eye on things -- I would be really disappointed to discover I now have to actively go search out what's going on by digging into issues and PRs. John

Re: [PHP-DEV] [VOTE] Interface Default Methods

e better served with interfaces + default implementations; they use inheritance only because it is currently the least bad way to make them work. Inheritance doesn't really capture the relationship between them (which is that there is none, save for their shared interface). -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

the criticisms I saw, but if I missed anything, please let me know and I’ll respond once I have a chance. After I get back home, I’ll update the RFC with the results of this thread and bring it to a vote. Thanks, -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, vi

Re: [PHP-DEV] Request for couple memory optimized array improvements

Under Discussion, and presuming a vote passes, I'll update the patch as necessary to work against 8.0. But my time is limited and I'm not willing to put further time into the code unless an RFC vote passes. Thoughts anyone? -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Guard statement

plexity in the parser and remove the runtime handling. It would obviously be preferable if the compiler can catch errors in all cases, but when it can't (and php's dynamicity makes this a hard problem), I think it's acceptable that the runtime can serve as a fallback. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

till not conflict with a function call, because the 'else' keyword after the close parenthesis would not be valid syntax immediately following a function call. So the main question there is, is the parser sufficiently smart to be able to see 'guard' and look ahead for the

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

else ...". In this context, guard could not possibly be confused with a function from the parser's point of view, instead serving as an intent modifier to if. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

maybe even goto, as appropriate to the condition and its parent block, which could be any functional block — a function, loop, if, else, try, or catch clause, or the "global" scope outside of a function or class definition. And, if you did return (as opposed to something else), you'd retain locality of 'return' and the return value, rather than separating it with the condition. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Named arguments

Hi Rowan, > On May 5, 2020, at 16:47, Rowan Tommins wrote: > > Hi John, > > On 05/05/2020 18:27, John Bafford wrote: >> I very much do like the idea of named parameters, but I do not like the >> specific proposal in the linked RFC at all. I think that treating nam

Re: [PHP-DEV] [RFC] Named arguments

like this: $collection->firstIndex(of: $element); $collection->firstIndex(where: $someCallback); which is less typing, presuming your IDE didn't offer autocomplete for you anyway. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Named arguments

_:) \DateTime::class: self::specialDateComparator(_:_:), A::class: A::compare(_:_:), B::class: B:compare(first:second:), C::class: function($a, $b) {...}, ]; usort($array, $comparators[$eltType]); But that's definitely getting into future-scope possibilities. Thank you for your consideration. I can more fully flesh this out into an alternative RFC if people would like. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Typed array properties V2

array type enforcement, but having not fully read the thread, I'll keep that to myself until I have a chance to see that I have anything that's actually novel. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Typed array properties V2

th syntaxes as described above ([KeyType : ValueType] is exactly the same as Dictionary), but the shorter bracket syntax is preferred for readability. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

will empower the neutral and good actors in bringing about censure and rehabilitation of those not acting in the public interest. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Back to the code (was Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct))

I wish we didn’t have to talk about this. But silencing the conversation and wishing the problem away doesn’t fix the the giant elephpant in the room. It just *makes it worse*. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PR #1723 - fix for crash in mysqli_connect

t.s. Thanks! -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

Sascha, > On Jan 12, 2016, at 11:17, Sascha Schumann > wrote: > > Hi John, > >> And it is *not* acceptable. > > May I ask who put you in charge to determine whether something is "acceptable" > or "reprehensible”? *I* avoid internals because *I* b

[PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

shitpile needs to be fixed. Internals needs to *accept* there’s a problem, and *actually do* something about it. Once internals *actively puts forth effort* to counter its toxic reputation, by *being less toxic*, it will be much easier to attract new talent. Do that first. The rest will follow. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Internals and Newcomers and the Sidelines (WAS: Adopt Code of Conduct)

ey get to say, "what a bunch of amateurs, the language devs can't even discuss a code of conduct without calling each other nazis". Stop the nonsense. Get better, grow up, treat each other with respect, and act like the adults you are. I'd like to work with you all, but yo

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

hout calling each other nazis". Stop the nonsense. Get better, grow up, treat each other with respect, and act like the adults you are. I'd like to work with you all, but you make it dammned hard to want to. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] array_key_(first|last|index) functions proposal

Hi Andrea, > On Jan 4, 2016, at 12:05, Andrea Faulds wrote: > > Hi John, > > John Bafford wrote: >> Happy New Year, everyone! >> >> I’d like to present the first new PHP RFC for this year, a proposal to add >> functions to easily get the first, l

Re: [PHP-DEV] RFC Operator Overloading in Userspace

em I see with this, besides the parser complexity it would entail, is that it would make static analysis that much harder, and you wind up with PHP code that can’t actually compile unless the operator definitions are loaded. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

> On Jan 1, 2016, at 16:38, Bishop Bettini wrote: > > On Fri, Jan 1, 2016 at 3:44 PM, John Bafford wrote: > Happy New Year, everyone! > > I’d like to present the first new PHP RFC for this year, a proposal to add > functions to easily get the first, last, or an arbitra

[PHP-DEV] [RFC] array_key_(first|last|index) functions proposal

/array_key_first_last_index PR: https://github.com/php/php-src/pull/347 Thanks, -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

> On Jan 1, 2016, at 15:20, Johannes Schlüter wrote: > > On Fri, 2016-01-01 at 13:28 -0500, Bishop Bettini wrote: >> Hi, and happy New Year! >> >> Now that the big push for PHP 7 is done, I'd like to revive earlier >> discussions >>

[PHP-DEV] Re: [RFC] GitHub Pull Requests Triage Team

help make it easier to include new people in the project, since those are the sort of low-hanging fruit that new devs often start with. > Thoughts? > > Thanks, > bishop -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Void Return Type RFC

hat change to only the return type and not also the return itself is a potentially dubious win given the potential technical complexity involved in implementing this. Thoughts? -John > On Oct 30, 2015, at 04:38, Chris Riley wrote: > > Hi, > > I'm still not sure why we are

Re: [PHP-DEV] Let's discuss enums!

So you might want to say something like: enum FormEvents { PRE_SUBMIT, PRE_BIND = PRE_SUBMIT, //deprecated name, provide mapping to new name } Another good reason for wanting to provide values is so that you could write code like this: $eventHandlers = [ FormEvents::PRE_SUBMIT => function() { … }, FormEvents::POST_SUBMIT => function() { … }, ... ]; Although maybe the ideal solution here would be to allow for array indexes to have more types than just int and string (so that the array index actually is the enum, not some serialized representation). -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Let's discuss enums!

> On Sep 17, 2015, at 20:06, Bob Weinand wrote: > >> Am 18.09.2015 um 01:52 schrieb John Bafford : >> >> If we’re bikeshedding, one feature I would really like to see, with >> typehinting, is warnings if all cases of an enum aren’t handled in a switch. >>

Re: [PHP-DEV] Let's discuss enums!

would be very handy if an enum value is added after initial development and someone misses a switch statement in cleanup. The typehint would also allow generating a warning if someone did something like switch(Weekday $someWeekday) { //case … all the weekdays: break; case ‘I am

Re: [PHP-DEV] Generic classes and methods RFC

e I understand, how does this interact with strict types (and non-strict)? new Entry(1, 2);//I assume it should type-juggle declare(strict_types = 1); new Entry(1, 2);//I assume it should throw error I'm interested to see if PHP can get generics going. I hope hashing out some more details might garner more interest. Thanks, John

Re: [PHP-DEV] RFC: Nested enclosing returns

potential security concerns? Are there any other languages that make something like this possible? I suspect that any code that could be “improved” with this functionality is already in significant need of improvement by more conventional means. -John -- PHP Internals - PHP Runtime Develop

Re: [PHP-DEV] RFC - Array slice syntactic sugar

omething like that. First element can > be easily accessed with reset and each/current, but the last one is > harder to access without modifying. So maybe it's be a good addition. > There's a lot of time till 7.1 yet so you could definitely make a good RFC. reset + each/current

Re: [PHP-DEV] RFC - Array slice syntactic sugar

few functions. (PR here: https://github.com/php/php-src/pull/347) If people are generally interested in having an array_key_(first|last|index) implementation, I can dust off that PR, update it for master, and if we really need an RFC, I’ll prepare one for PHP 7.1. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Array slice syntactic sugar

t; 3 is currently valid syntax, and means $foo ? ($bar < 1) : (2 > 3) So there is probably some complex nesting of ?: and <:> that is entirely ambiguous. Not necessarily saying it can’t be done, but I think we should probably avoid syntax with a significant chance of causin

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> 2 > php > echo (a^b) . "\n"; > 3 > php > > > However: `☃` has a long history of being available to PHP. > > S > There’s no existing unary form of * and ^, though, so I think they’d both be available in this context (^ is my preference). Overloading unary & would probably also work in this context, but personally, I think that & is too overused. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC - Array slice syntactic sugar

such as $thing[@0], > $thing[@-1], etc. I would just like to point out that the @ error suppression operator operates on expressions. Unfortunately, that means that also using @ as a slice operator makes the two ambiguous with each other in those contexts. The concept itself can still w

  1   2   3   4   5   6   >