Re: [PHP-DEV] RFC: Interest in function autoloading?

> I've searched the archive, but I haven't found anything about this issue.  > I notice there exists an RFC for autoloading of functions, or more to the > point, a unified autoloading system for classes, functions, constants and > streams: Hi Terje, I'd brought this up 2 months ago in https://e

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

> On Mar 16, 2020, at 9:20 PM, Dan Ackroyd wrote: > > On Mon, 16 Mar 2020 at 18:29, Mike Schinkel wrote: >> >> Would it be possible to add a feature when voting were people either need to >> type in >> a one to two sentence reason why they voted "no" on a proposal > > Pretty strong no for me.

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

On Mon, Mar 16, 2020 at 8:20 PM Dan Ackroyd wrote: > * Explaining exactly why you're voting no can be hard as there can be > multiple overlapping reasons for voting no. > > * It sets up arguments about what is and isn't a valid reason for voting no. > > * It drives people who might want to vote no

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni wrote: > Let me know what you think! Thank you for your feedback so far! I'd be really curios to know what authors of the referenced RFCs think about this, f.ex. Michał (brzuc...@php.net), Andrey (andrewg...@rambler.ru) and Nikita (ni...@php.net) Is

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 16, 2020 at 8:29 PM Marco Pivetta wrote: > That kinda makes the entire feature quite useless/uninteresting to me: if a > this does is desugaring into a set of assignments, then I'm not sure what its > advantage is. I'm sorry about that, but the motivation of the RFC is quite clear in

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 16, 2020 at 10:40 AM Rowan Tommins wrote: > Thanks for having another go at this feature, which I think a lot of people > would like in some form. I agree! > Maybe we want to have all four, but that would leave us with a lot of > different ways of initialising objects, which might not

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

> On Mar 16, 2020, at 13:48, Sara Golemon wrote: > >  >> On Mon, Mar 16, 2020 at 12:49 PM Ben Ramsey wrote: > >> > On Mar 16, 2020, at 12:48, Sara Golemon wrote: >> > >> > On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey wrote: >> > I’m currently working on a patch for this, so this might help

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Hey Jakob, On Tue, Mar 17, 2020, 02:27 Jakob Givoni wrote: > On Mon, Mar 16, 2020 at 9:31 AM Marco Pivetta wrote: > > What happens if you have an expression that throws? > > > > class Foo > > { > > public $a; > > public $b; > > public $c; > > } > > > > $instance = new Foo(); > > > >

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 16, 2020 at 9:31 AM Marco Pivetta wrote: > What happens if you have an expression that throws? > > class Foo > { > public $a; > public $b; > public $c; > } > > $instance = new Foo(); > > function iThrow() { > throw new \Exception(); > } > > try { > $foo ->[ >

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 16, 2020 at 9:26 AM Christian Schneider wrote: > [] suggests an array but then is uses literals and = instead of > 'strings'/$vars and => which looks wrong to my PHP eye. That's ok, square brackets are usually related to arrays and what I want is something similar to array literals. T

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

On Mon, 16 Mar 2020 at 18:29, Mike Schinkel wrote: > > Would it be possible to add a feature when voting were people either need to > type in > a one to two sentence reason why they voted "no" on a proposal Pretty strong no for me. * Explaining exactly why you're voting no can be hard as there

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, Mar 16, 2020 at 9:10 AM Matthew Brown wrote: > I love the idea! Thanks Matthew! > The syntax for new objects looks a little verbose – would it be possible to > use > > $foo = new Foo()[ > property1 = "hello", > property2 = 5, > ]; The short answer: I don't think so. This is not poss

[PHP-DEV] RFC: Interest in function autoloading?

Hi guys. I've searched the archive, but I haven't found anything about this issue. I notice there exists an RFC for autoloading of functions, or more to the point, a unified autoloading system for classes, functions, constants and streams: https://wiki.php.net/rfc/function_autoloading Our s

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

On Mon, Mar 16, 2020, at 11:25 AM, Nicolas Grekas wrote: > > > I repeat what I wrote before but all those problems would disappear if we > > > were to bind the proposal to visibility: > > > https://externals.io/message/108675#108753 > > > > > > We could even consider splitting "read" and "write" in

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel wrote: > If we had that we could list the reasons and the number of votes that choose > those reasons on the RFC for historical purposes. Thanks Mike, exactly what I was thinking when I started writing RFC: COPA (https://wiki.php.net/rfc/compact-obje

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

On Mon, Mar 16, 2020 at 12:49 PM Ben Ramsey wrote: > > On Mar 16, 2020, at 12:48, Sara Golemon wrote: > > > > On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey wrote: > > I’m currently working on a patch for this, so this might help with one > aspect of your proposal. > > > > Here's a quick&dirty for

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

For reference: https://wiki.php.net/rfc/object-initializer https://externals.io/message/106947 That was quite the discussion, and it started only 6 months ago. -Mike > On Mar 16, 2020, at 10:10 AM, Matthew Brown wrote: > > I love the idea! > > The syntax for new objects looks a little verb

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

> On Mar 16, 2020, at 12:04 PM, Paul M. Jones wrote: > > Turning it over in my mind, I wonder if maybe a `Sapi` prefix would be a > better alternative along this path, especially since these objects relate to > the "interface between web server and PHP." >

[PHP-DEV] Capturing reasons for votes for historical sake?

Hi all, Seeing people referencing former RFCs that failed when someone brings up an RFC (which is a good thing to reference, BTW) I am finally compelled to comment in hope there would be will to improve it. When court justices rule on important decisions they write opinions, or join with the m

Re: [PHP-DEV] [RFC] [VOTE] str_contains is accepted

> On Mar 16, 2020, at 12:59, Guilliam Xavier wrote: > > On Mon, Mar 16, 2020 at 10:43 AM Philipp Tanlak > wrote: >> >> Hello internals! >> >> Two weeks have passed since the voting on the str_contains RFC started. >> https://wiki.php.net/rfc/str_contains >> With a result of 43 (Yes) to 9 (No),

Re: [PHP-DEV] [RFC] [VOTE] str_contains is accepted

On Mon, Mar 16, 2020 at 10:43 AM Philipp Tanlak wrote: > > Hello internals! > > Two weeks have passed since the voting on the str_contains RFC started. > https://wiki.php.net/rfc/str_contains > With a result of 43 (Yes) to 9 (No), the RFC was accepted and the voting > phase has been closed. > > If

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

> On Mar 16, 2020, at 12:48, Sara Golemon wrote: > > On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey wrote: > I’m currently working on a patch for this, so this might help with one aspect > of your proposal. > > Here's a quick&dirty for AF_PACKET, looks like OSX/BSD might need AF_LINK > though...

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

On Mon, Mar 16, 2020 at 11:17 AM Ben Ramsey wrote: > I’m currently working on a patch for this, so this might help with one > aspect of your proposal. > > Here's a quick&dirty for AF_PACKET, looks like OSX/BSD might need AF_LINK though... https://github.com/php/php-src/compare/master...sgolemon:

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

> On Mar 16, 2020, at 11:22, Aran Reeks wrote: > > Hi Ben, > > Thanks for the feedback, I wasn't aware of net_get_interfaces, but that's > really helpful and agree that post your patch, implementing a > get_network_mac_addr() function (or similar name) would be amazing. > net_get_interfaces

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

> > I repeat what I wrote before but all those problems would disappear if we > > were to bind the proposal to visibility: > > https://externals.io/message/108675#108753 > > > > We could even consider splitting "read" and "write" in two separate > > keywords, each bound to visibility, isn't it? > >

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

Hi Ben, Thanks for the feedback, I wasn't aware of net_get_interfaces, but that's really helpful and agree that post your patch, implementing a get_network_mac_addr() function (or similar name) would be amazing. Many thanks Aran On Mon, 16 Mar 2020 at 16:16, Ben Ramsey wrote: > > On Mar 16, 2

Re: [PHP-DEV] [DISCUSSION] Native UUID support in PHP

> On Mar 16, 2020, at 11:06, Aran Reeks wrote: > > Hi Internals, > > I'd like to open up a discussion around the implementation of a new > function within PHP for generating a UUID. > > Whilst there are libraries out there already for PHP which can generate a > UUID, all of those libraries have

[PHP-DEV] Re: [DISCUSSION] Native UUID support in PHP

On 16.03.2020 at 17:06, Aran Reeks wrote: > I'd like to open up a discussion around the implementation of a new > function within PHP for generating a UUID. > > Whilst there are libraries out there already for PHP which can generate a > UUID, all of those libraries have the possibility to generate

[PHP-DEV] [DISCUSSION] Native UUID support in PHP

Hi Internals, I'd like to open up a discussion around the implementation of a new function within PHP for generating a UUID. Whilst there are libraries out there already for PHP which can generate a UUID, all of those libraries have the possibility to generate IDs that *could* have a collision.

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

Hi all, > On Mar 14, 2020, at 10:18, Rowan Tommins wrote: > >> On 13/03/2020 20:36, Larry Garfield wrote: >> >>> * The RFC by design is trying to take the super-globals and make them OOPy; >>> no more, no less. >>> * The super-globals are not based on HTTP. They're based on CGI, which is >>>

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

On Mon, Mar 16, 2020, at 6:57 AM, Nicolas Grekas wrote: > Le lun. 16 mars 2020 à 12:52, Máté Kocsis a écrit : > > > > > > > The other one is the recently declined > > > https://wiki.php.net/rfc/object-initializer. As it basically works by > > > first > > > creating the object normally (including

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

On Mon, 16 Mar 2020 at 11:48, Jakob Givoni wrote: > https://wiki.php.net/rfc/compact-object-property-assignment > - A pragmatic approach to object literals > > Let me know what you think! > Hi Jakob, Thanks for having another go at this feature, which I think a lot of people would like in some

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

On Mon, 16 Mar 2020 at 15:01, Paul M. Jones wrote: > That escalated quickly. :-) I'm going to reply to the only request for > clarification I could identify in this exchange -- if I missed others, > please let me know. > Hi Paul, Did you see the naming suggestion from Larry of CgiRequest/CGIR

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

Hi all, That escalated quickly. :-) I'm going to reply to the only request for clarification I could identify in this exchange -- if I missed others, please let me know. >> Is the proposal really suggesting that a developer would still need to do >> `if(!empty($request->server[‘HTTPS’]) && $r

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Hey Jakob, What happens if you have an expression that throws? class Foo { public $a; public $b; public $c; } $instance = new Foo(); function iThrow() { throw new \Exception(); } try { $foo ->[ a = 'a', b = iThrow(), c = 'c', ]; } catch (\Throwab

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Am 16.03.2020 um 12:48 schrieb Jakob Givoni : > I'm opening up my new RFC for discussion: > > https://wiki.php.net/rfc/compact-object-property-assignment > - A pragmatic approach to object literals > > Let me know what you think! Sorry to say but the syntax look very un-PHP-like. [] suggests an

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

I love the idea! The syntax for new objects looks a little verbose – would it be possible to use $foo = new Foo()[ property1 = "hello", property2 = 5, ]; as an alternative to $foo = (new Foo())->[ property1 = "hello", property2 = 5, ]; On Mon, 16 Mar 2020 at 07:48, Jakob Givoni wrote

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

Le lun. 16 mars 2020 à 12:52, Máté Kocsis a écrit : > > > > The other one is the recently declined > > https://wiki.php.net/rfc/object-initializer. As it basically works by > > first > > creating the object normally (including a possible constructor call), and > > then assigning the specified pro

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

> > The other one is the recently declined > https://wiki.php.net/rfc/object-initializer. As it basically works by > first > creating the object normally (including a possible constructor call), and > then assigning the specified properties, this would not be compatible with > readonly properties t

[PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

Hello Internals, I'm opening up my new RFC for discussion: https://wiki.php.net/rfc/compact-object-property-assignment - A pragmatic approach to object literals Let me know what you think! Best, Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.ph

[PHP-DEV] Re: [VOTE] get_debug_type

On 01/03/2020 13:29, Mark Randall wrote I have opened voting on the get_debug_type RFC: https://wiki.php.net/rfc/get_debug_type Voting will run for 2 weeks and will close 2020-03-16. Voting has now closed. The RFC has passed with 41 in favour and 3 against. -- Mark Randall marand...@php.net

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

On Mon, Mar 16, 2020 at 4:47 AM Rowan Tommins wrote: > I'm sure different people will react differently, but my intuition is quite > the opposite: I would probably call the inline assignment to the property > an "initial value", not a "default value", and I would intuitively compare > it to assign

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

On Mon, Mar 16, 2020 at 12:23 AM Larry Garfield wrote: > On Sun, Mar 15, 2020, at 4:44 PM, Máté Kocsis wrote: > > > > > > Avoiding that confusion will save the industry millions of dollars. > > > > > > > On the one hand, you are right, because currently it's not very useful to > > effectively pro

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

On Sun, 15 Mar 2020 at 21:41, Jakob Givoni wrote: > On Sun, Mar 15, 2020, at 8:48 AM, Marco Pivetta wrote: > > I think what will happen is that people will start requesting for > read-only > > properties with default values to be over-writable-once > > Exactly, I think that intuitively, developer

[PHP-DEV] [RFC] [VOTE] str_contains is accepted

Hello internals! Two weeks have passed since the voting on the str_contains RFC started. https://wiki.php.net/rfc/str_contains With a result of 43 (Yes) to 9 (No), the RFC was accepted and the voting phase has been closed. If there are no issues with the implementation, the change can be merged i

[PHP-DEV] PDO parser: drop support for backslash escapes

Hi all, as it is now (for a long time), the PDO parser supports the proprietary backslash escapes for (double-)quotes in SQL string literals (the standard way to escape quootes in SQL strings is to double them). This causes string terminating quotes to be not recognized as such whenever they are