On Tue, 19 Feb 2019 at 17:33, Larry Garfield wrote:
> On Tuesday, February 19, 2019 3:38:16 AM CST Rowan Collins wrote:
> > On Tue, 19 Feb 2019 at 02:44, Larry Garfield
> wrote:
> > > Yes, a lot of existing code uses arrays as anonymous structs. Such
> code
> > > is,
> > > IMO, "doing it wrong"
On Mon, 18 Feb 2019 at 17:26, Larry Garfield wrote:
> On Sunday, February 17, 2019 9:24:05 AM CST Girgias wrote:
> > Greetings internals,
> >
> > I would like to have your opinion on being able to type hint arrays and
> > objects which implement
> > array-lik
Greetings internals,
I would like to have your opinion on being able to type hint arrays and
objects which implement
array-like interfaces (notably ArrayAccess, Countable, and Iterator) as
currently if a function /method only needs one specific feature of an array
and is willing to accept array-li
On Fri, 8 Feb 2019 at 13:13, Robert Korulczyk wrote:
> Sounds like an arbitrary interpretation. Treating `?mixed" as "top type"
> (including null) would be more practical and consistent with other
> type-hints.
>
> Regards,
> Robert Korulczyk
>
The whole PHP Documentation is based around the fac
On Thu, 7 Feb 2019 at 02:03, Pierre Joye wrote:
> Good morning Nikita,
>
> On Tue, Nov 27, 2018, 4:43 AM Nikita Popov
> > Hi internals,
> >
> > When the silencing operator @ is used, the intention is generally to
> > silence expected warnings or notices. However, it currently also silences
> >
On Tue, 5 Feb 2019 at 17:06, Dennis Birkholz
wrote:
> So I would really prefer the WeakReference class would just be
> serializable with all the consequences you outlined. Maybe for PHP 8 we
> will decide to require all classes to be serializable except classes
> that implement the Unserializable
On Tue, 5 Feb 2019 at 14:29, Nikita Popov wrote:
> On Tue, Feb 5, 2019 at 1:23 PM Girgias wrote:
>
>> On Tue, 5 Feb 2019 at 12:22, Nikita Popov wrote:
>>
>>> [. . .]
>>>
>>
>> I'm all for it but what is the scope of the RFC?
>> Is
On Tue, 5 Feb 2019 at 12:22, Nikita Popov wrote:
> Hi internals,
>
> I'd like to bring forward the following proposal for PHP 8, which will make
> (zpp) parameter parsing failures always result in a TypeError (rather than
> generating a warning+null, depending on circumstances):
>
> https://wiki.
On Mon, 4 Feb 2019 at 13:28, Wes wrote:
> I know this too. I am often in touch with Levi and void variance is not
> covered by his RFC
> As a matter of fact, if you try to compile that PR void will behave exactly
> like it does now
>
First of all, apologies as I needed a brush up on the differen
I know this, I am talking about this RFC
https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
Which has been voted and implementation is being worked on a GitHub PR:
https://github.com/php/php-src/pull/3732
Your proposal doesn't bring anything new to the table that this RFC does
This is normal the Covariance/Contravariance is coming in PHP 7.4 not
before.
This RFC would also target PHP 7.4 so I don't see how this RFC would change
the PHPUnit problem.
George P. Banyard
On Mon, 4 Feb 2019 at 12:54, Wes wrote:
> Nope, it's not. https://3v4l.org/N4LNb It should've been fi
Isn't this "fixed" with the Covariance/Contravariance RFC which has been
voted recently
George P. Banyard
On Mon, 4 Feb 2019 at 08:58, Wes wrote:
> Hi!
>
> PHPUnit 8 changed e.g. ` function setUp(){}` to ` function setUp():
> void{} ` and a lot of people did not like being forced to do t
On Thu, 24 Jan 2019 at 01:25, Dan Ackroyd wrote:
> On Wed, 23 Jan 2019 at 17:25, Girgias wrote:
>
> > I understand the rationale for functional programming, may I ask
> > in your opinion should PHP have built-in functions for arithmetic
> > operations so that it c
On Wed, 23 Jan 2019 at 18:30, Rowan Collins wrote:
> On Wed, 23 Jan 2019 at 17:25, Girgias wrote:
>
> > I understand the rationale for functional programming, may I ask
> > in your opinion should PHP have built-in functions for arithmetic
> > operations so that it c
On Wed, 23 Jan 2019 at 16:23, Dan Ackroyd wrote:
> On Tue, 22 Jan 2019 at 20:34, Girgias wrote:
> >
> > a list of functions which seem reasonable to deprecate
>
> > Classes/Objects functions:
> >
> >- is_a (use instanceof operator)
>
> This is a
On Wed, 23 Jan 2019 at 15:43, Claude Pache wrote:
> So, since you didn’t see, here are some practical usages of settype():
>
> function foo($bar) {
> // $bar is supposed to be either a string, or a list of strings
> settype($bar, 'array');
> // ...
> }
>
> function qux($id) {
>
On Wed, 23 Jan 2019 at 09:02, Markus Fischer wrote:
> Hi,
>
> On 22.01.19 21:34, Girgias wrote:
> > - phpversion (use PHP_VERSION constant)
>
> The function takes an optional argument `string $extension`, what is the
> replacement for that?
>
Didn 't realis
On Tue, 22 Jan 2019 at 23:28, Yasuo Ohgaki wrote:
> On Wed, Jan 23, 2019 at 7:08 AM Girgias wrote:
>
> > On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki wrote:
> >
> >> Hi Girgias
> >>
> >> It seems good list in general.
> >> There would not b
On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki wrote:
> Hi Girgias
>
> It seems good list in general.
> There would not be issues marking them as deprecated.
> "Deprecation" means "Soft deprecation", correct?
>
> Removing these aliases from PHP 8 is not go
On Tue, 22 Jan 2019 at 21:48, Stephen Reay wrote:
>
> > On 23 Jan 2019, at 03:34, Girgias wrote:
> > Classes/Objects functions:
> >
> > - is_a (use instanceof operator)
> > - is_subclass_of (not exactly what it's purpose is but the instanceof
> &
Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in
21 matches
Mail list logo
