Re: [PHP-DEV] List of attributes

> On Oct 30, 2020, at 14:28, Rowan Tommins > wrote: > >> 3. Vote to switch to a less verbose syntax [...] >>The downside is that... > > Let me stop you there. The downside is that a mob of Internals regulars will > come to your house and lynch you for asking

Re: [PHP-DEV] Proposal for a RFC

> On May 4, 2019, at 11:08, Kalle Sommer Nielsen wrote: > > Hi > > Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade : >> >> Hi Internals team! >> >> I have an idea for a feature that I'd love to see in the language one day >> and wanted to run the idea by you all. >> >> The idea is to add

Re: [PHP-DEV] Proposal for a RFC

Hi Steven, > The idea is to add a new magic method "__toArray()" that would allow a > developer to specifiy how a class is cast to an array. The idea is the same > mentality of __toString(), but, for arrays. I'd like to see this as well. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jone

Re: Re: [PHP-DEV] [VOTE] Deprecate left-associative ternary

Hi all, > On Apr 24, 2019, at 11:27, Nikita Popov wrote: > > To better judge the BC impact here, I've analyzed the top 1000 composer > packages for this pattern. The results are here: > https://gist.github.com/nikic/b6214f87b0e4a7c6fe26919ac849194f I *love* research like this. Really nicely do

Re: [PHP-DEV] RFC: Locked Classes

> On Mar 10, 2019, at 13:35, Rowan Collins wrote: > > Hi all, > > I'd like to present a new RFC for "locked classes": classes which restrict > dynamically adding or removing properties from their instances. Nice. This would help enforce at least one element of immutability in userland; nam

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

All, I have managed to avoid commenting on PHP-FIG since the group was dissolved, then re-constituted under the same name, without my participation as one of its original founding members. However, I cannot let this phrasing pass: On Feb 1, 2019, at 10:30, Larry Garfield wrote: > FIG today i

Re: [PHP-DEV] [RFC] abolish narrow margins

> On Jul 11, 2018, at 12:10, Sara Golemon wrote: > > On Wed, Jul 11, 2018 at 12:41 PM, Joe Watkins wrote: >> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote >> in the very near future ... >> >> We discussed it a year ago, and discussion died down to nothing (possibl

Re: [PHP-DEV] [RFC] Mixed type

> On Jun 30, 2018, at 15:17, Sara Golemon wrote: > > I'm not super excited about this RFC because, as you say, this information > could be easily encoded into the docblock for the function/method. I would enjoy a 'mixed' typehint for exactly that reason; i.e., that I don't have to put it in

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

> On Feb 25, 2018, at 12:59, Silvio Marijić wrote: > > Here is link to tweet > https://twitter.com/SilvioMarijic/status/965564630071300096 After having read that, I think "immutable" is still perfectly reasonable. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Leg

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

> On Feb 25, 2018, at 11:29, Silvio Marijić wrote: > > I had discussion on Twitter regarding semantics of keyword 'immutable'. Can you link to the discussion? I am interested to read it. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP http

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

Hi Silvio, I like the RFC. * * * I would like to see arrays allowed as immutable properties. In I wrote that arrays are "probably not practical in most situations" because you have to "recursively scan through array properties to make sure that they con

Re: [PHP-DEV] var_export() array format

> On Feb 17, 2018, at 18:27, Andreas Hennings wrote: > > What we can do is add a third parameter with flags. Big +1. When writing tests and setting the $expected value, one of the constantly recurring drudgeries is reformatting the correct var_export($actual) output from arrays to match the

Re: [PHP-DEV] Mailing list moderation

> On Jan 3, 2018, at 12:59, Joe Watkins wrote: > > Let's remember that there are a large number of people on the sidelines that > are not subscribed to the list directly, but choose to use news readers, or > the excellent externals.io; They may not able to filter messages from any > individua

Re: [PHP-DEV] Mailing list moderation

> On Jan 3, 2018, at 12:35, Joe Watkins wrote: > > You don't get to conduct yourself however you want without consequence. Sure. The question then, is, what is the proper consequence? I hold that it is not "banning" or "suspension" (which may or may not actually be within the delegated powers

Re: [PHP-DEV] Mailing list moderation

> On Jan 2, 2018, at 12:29, Dustin Wheeler wrote: > > On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison wrote: >> >> I doubt we have any official procedures. I agree with the proposed >> suspension as long as the suspension for a set amount of time; I >> believe in giving people a chance to refor

Re: [PHP-DEV] A validator module for PHP7

> On Sep 4, 2017, at 18:06, Marco Pivetta wrote: > > On Mon, Sep 4, 2017 at 8:56 PM, Crocodile wrote: > >> In most cases users would like more than just valid/invalid, i. e. which >> particular rule(s) failed and also human-readable error messages. As of >> simple validation that is almost alw

Re: [PHP-DEV] Re: Changes to SuperGlobals for PHP 8 (was: somethingabout session_start...)

> On Jul 29, 2017, at 11:58, Andrea Faulds wrote: > > Come to think of it, can we fix $_FILES while we're at it? :p Not to be a broken record here, but this is something the `request` extension does as well. In other words, a starting point for a lot of this work already exists. -- Paul M.

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

> On Jul 29, 2017, at 05:27, Dan Ackroyd wrote: > > Designing classes/interfaces to be correct the first time is a really > difficult thing to do, and then maintaining classes/interfaces is hard > as any change to a method is a BC break. Having done it several times before in userland helps. P

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

> On Jul 28, 2017, at 10:11, Sara Golemon wrote: > > 3. I'm definitely not decided on what I'd like from default session > behavior. An error isn't out of the question, for sure. If this kind of big change is being contemplated, I would very much be in favor of decoupling the various combined

Re: [PHP-DEV] [RFC] samesite cookie implementation

> On Jul 18, 2017, at 08:37, li...@rhsoft.net wrote: > > > > Am 18.07.2017 um 15:23 schrieb Frederik Bosch | Genkgo: >> Hi Andrey, >> Thanks for your feedback. If we are going to wait for http_cookie_set, then >> my guess will be that it will take a while before we see samesite cookie >> impl

Re: [PHP-DEV] Namespaces in Core

> On Feb 6, 2017, at 13:50, Peter Cowburn wrote: > > a vote which essentially is about adopting > namespaces in core, via new library RFC, is not the way to go about > changing our coding standards. In short, I don't want to the see the > situation where this extension gets merged in to 7.2 (wh

Re: [PHP-DEV] [RFC] Deprecate and Remove Bareword (Unquoted) Strings

> have drafted an RFC rather than trying to fit all the detail into one e-mail: > https://wiki.php.net/rfc/deprecate-bareword-strings > > Please read my proposal, and let me know your thoughts. I have placed the RFC > "under discussion", but will be happy to modify it based on feedback, and am

Re: [PHP-DEV] Not autoloading functions

> On Jan 20, 2017, at 01:04, Rasmus Schultz wrote: > > Just a quick thought. > > Since the autoloading functions proposal is stalled, how about allowing for > import of static functions instead? > >use function Foo::bar; > >bar(); // calls Foo::bar() > ... > at least we can move ahea

Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

Hi Arvids, > On Jan 10, 2017, at 17:22, Arvids Godjuks wrote: > > I would also add the support, bug and feature issues that will definitely > crop up with such an interface. If there is a major bug, flaw or security > issue, getting it fixed is going to be a problem, because as we know, the >

Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

> On Jan 7, 2017, at 15:41, Joe Watkins wrote: > > That doesn't sound like a positive consensus that this is a good idea, it is > rather the opposite. Not to get into interpretations of comments, but while I agree that there were one or two actual negatives, they were predicated on a misunder

Re: [PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

Hi all, Replying to both Marco Pivetta and Joe Watkins here, as some of their critiques overlap. I apologize in advance for the length of this email. * * * On Jan 6, 2017, at 10:47, Marco Pivetta wrote: > Bundling the [PSR-7] interface is no biggie, so I suggest steering away and > going tha

[PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

(This is a re-send, on a new thread, of the message originally posted at with some minor edits. The original was apparently not delivered to the entire list.) Hi all, I have prepared an RFC on server-side reques

Re: [PHP-DEV] Re: [RFC] ServerRequest and ServerResponse objects

> On Jan 6, 2017, at 12:51, Pierre Joye wrote: > > > > On Jan 5, 2017 3:12 AM, "Paul M. Jones" wrote: > On 2016-12-23 21:43:56 +, Andrea Faulds said: > > Hi, > > Since the $get, $post etc. properties are the same as $_GET and $_POST, does > that mean they retain the same name mangling

Re: [PHP-DEV] Re: [RFC] ServerRequest and ServerResponse objects

Hi Joe, > On Jan 6, 2017, at 10:56, Joe Watkins wrote: > > It may be that you need to leave it two weeks from about now, to be on the > safe side. I'm sure that's not too different from what you were planning > anyway. I am totally fine with that; I'm not in any particular hurry. :-) -- Pa

Re: [PHP-DEV] [RFC] ServerRequest and ServerResponse objects

> On Jan 6, 2017, at 08:34, Adam Baratz wrote: > > One request: could you update the RFC list[1] so this one is in the "under > discussion" section? Makes discovery easier. There's an RFC howto[2] that > should cover this. Thanks for pointing that out. Done! -- Paul M. Jones pmjone...@gmai

Re: [PHP-DEV] Re: [RFC] ServerRequest and ServerResponse objects

Hi all, Today marks two weeks since this RFC was introduced. As I said at the start, it's the holidays, so I expect to keep the discussion period open for longer than two weeks, but I am surprised at how little discussion there has been. I find it hard to imagine that all criticisms have been r

Re: [PHP-DEV][RFC][DISCUSSION] - Immutable classes and properties

> On Dec 12, 2016, at 13:36, Andrea Faulds wrote: > > Consider that some popular applications of immutability ultimately contain a > reference to something mutable: PSR-7's immutable HTTP message objects point > to mutable streams Which subverts its overall promise of immutability (and the st

Re: [PHP-DEV] Immutability RFC

> On Nov 19, 2016, at 13:22, Michał Brzuchalski > wrote: > > In Event Sourced application Aggregates and Entities are mutable but > pushing Events for later write but speaking of ValueObject which ideally > could be immutable classes there is must on immutability and AFAIK there is > no need fo

Re: [PHP-DEV] Immutability RFC

> On Nov 16, 2016, at 07:57, Silvio Marijić wrote: > > Hi, > > To anyone who is interested in this RFC. What do you think what behavour we > should have when you try to compare two immutable objects by identity like > this: I don't mean to be overly-nitpicky here, but it strikes me that the is

Re: [PHP-DEV] Server-Side Request/Response Objects

Hi all, First, I want to reiterate that my initial desire was to submit this to PECL, to give the project some exercise before bringing it to internals. If someone here can nudge the PECL folks about my account request, that'd be appreciated. Otherwise, I'm happy to continue the discussion here

[PHP-DEV] Server-Side Request/Response Objects

Hi all, tl;dr: Gauging interest in an extension for server-side PHP request and response objects (*not* HTTP messages per se; see below) prior to writing an RFC for them on the wiki. * * * From time to time we've all heard the complaint that PHP has no built-in request object to represent the

Re: [PHP-DEV] Fixing halfway implemented session management - timestamp based session management OR remove session_regenerate_id()

> On Sep 25, 2016, at 16:40, Thomas Bley wrote: > > why not have a new session module? those who want no change for existing > applications keep the old one, new projects can use the new one, those who > want more security port their code to the new one. e.g. use session2_start(), > etc. If

Re: [PHP-DEV] [RFC] Pipe Operator

> On Apr 29, 2016, at 14:58, Sara Golemon wrote: > > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator I like this a lot. -- Paul M. Jones http://paul-m-jones.com --

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

> On Apr 7, 2016, at 07:21, Andrea Faulds wrote: > > Hi everyone, > > Bob and I have made an RFC which proposes an alternative syntax for list(): > > https://wiki.php.net/rfc/short_list_syntax > > Please tell us your thoughts. Reading the name of the RFC led me to imagine what I thought it m

[PHP-DEV] CVS Account Request: pmjones

Access to the PEAR module to maintain File_IMC and other packages -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php