Re: [PHP-DEV] Bump required libcurl version to 7.17.1

2020-01-10 Thread Pierre Joye
Good morning Christoph, I would even bump it to a much more recent version for 8.x or we will have the same issue during 8.x lifetime (we may anyway but starting with a 10+ years old version makes it much more likely). Best, On Wed, Jan 8, 2020 at 9:50 PM Christoph M. Becker wrote: > > Hi all,

Re: [PHP-DEV] [RFC] Static return type

2020-01-10 Thread Mike Schinkel
> On Jan 10, 2020, at 1:19 PM, Andreas Hennings wrote: > > This would work, but: > ": $this". With fluent + static I would have to look in two places. How about :fluent? This would indicate both a type and a further constraint meaning $this. Something to consider...? -Mike -- PHP

Re: [PHP-DEV] What to do with "$array[foobar]"?

2020-01-10 Thread Mike Schinkel
> On Jan 10, 2020, at 2:58 PM, Stanislav Malyshev wrote: > > The first part seems to make sense but I don't think losing "$array[0]" > does... I get the consistency argument but I feel most people would > rather have this useful syntax working and not worry about the fact that > it's

Re: [PHP-DEV] [RFC] Allow ::class on objects

2020-01-10 Thread Rowan Tommins
On 10/01/2020 17:29, Larry Garfield wrote: But having some kind of working way to reference a function that doesn't involve concatenating a string onto a namespace constant would be*super* nice. Whether it's called ::func or ::nameof I don't much care. Viz, replace this: $func =

Re: [PHP-DEV] What to do with "$array[foobar]"?

2020-01-10 Thread Stanislav Malyshev
Hi! > I think there's two ways to address this. One is to deprecate and > eventually remove the non-wrapped array interpolation syntax entirely, > requiring people to use the generic "{$array['foobar']}" syntax instead. > For the sake of consistency, I think this would also include deprecating >

Re: [PHP-DEV] [RFC] Static return type

2020-01-10 Thread Andreas Hennings
On Thu, 9 Jan 2020 at 20:53, Dik Takken wrote: > On 09-01-2020 17:52, Andreas Hennings wrote: > > On Thu, 9 Jan 2020 at 16:31, Nikita Popov wrote: > > > >> On Thu, Jan 9, 2020 at 4:06 PM Rowan Tommins > >> wrote: > >> > >> An argument could be made that $this does also specify a certain >

Re: [PHP-DEV] [RFC] Allow ::class on objects

2020-01-10 Thread Larry Garfield
On Thu, Jan 9, 2020, at 6:10 PM, Marcio Almada wrote: > Em qui., 9 de jan. de 2020 às 20:57, Mike Schinkel > escreveu: > > > > > On Jan 9, 2020, at 6:53 PM, Marcio Almada wrote: > > > > > > Because we would be expanding a construct that already looks > > > inappropriate from a purely > > >

Re: [PHP-DEV] Initializing constants once, with code?

2020-01-10 Thread Robert Hickman
> > I stand by my comment that this has *some* of the same problems as a > > separate "build" script, such as the need to be configured correctly, > > I find repeating of this as overstating the concern simply because any > programming language feature would need to be used correctly. So this

Re: [PHP-DEV] [RFC] Allow ::class on objects

2020-01-10 Thread Guilliam Xavier
Hi, On Thu, Jan 9, 2020 at 10:02 PM Kalle Sommer Nielsen wrote: > > [...] > > use Interfaces; > if(!$object instanceof Interfaces\MyInterface) > { > // Notice the ! is right associative and instanceof is non > associative, hence the lack of parantheses > } Sorry for off-topic but that comment

Re: [PHP-DEV] What to do with "$array[foobar]"?

2020-01-10 Thread Guilliam Xavier
Hi, On Thu, Jan 9, 2020 at 1:05 PM Nikita Popov wrote: > > [...] we already support > "$string" and "$object->prop", so it is in a way natural that > "$array['key']" is also supported, as the last of the "fundamental" > variable syntaxes. What about rather deprecating "$object->prop" too? The