On 12/19/2017 7:32 AM, Stanislav Malyshev wrote:
> I'm not sure what's the point of it. "mixed" means "any type". Not
> writing a type means "any type". So why waste space and add something
> that contributes nothing when everybody is already using the current
> convention and the new one does not
Hi!
> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
> https://wiki.php.net/rfc/mixed-typehint
>
> The purpose of this RFC is to introduce "mixed" typehint on language level
> to be used
> as a valid typehint. PHP currently forces users to not use any type in case
> the
> type is
Am 19.12.2017 um 04:44 schrieb Michael Morris:
On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec
wrote:
Hello internals,
I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehint
The purpose of this RFC is to introduce "mixed" typehint on langu
On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec
wrote:
> Hello internals,
>
> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
> https://wiki.php.net/rfc/mixed-typehint
>
> The purpose of this RFC is to introduce "mixed" typehint on language level
> to be used
> as a valid typehi
Hello internals,
I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehint
The purpose of this RFC is to introduce "mixed" typehint on language level
to be used
as a valid typehint. PHP currently forces users to not use any type in case
the
type is mi
On Mon, Dec 18, 2017 at 2:31 PM, Sara Golemon wrote:
> On Mon, Dec 18, 2017 at 4:11 PM, Sara Golemon wrote:
>> On Mon, Dec 18, 2017 at 3:38 PM, Levi Morrison wrote:
Thoughts? If I don't hear anything in a week, I'll just apply to 7.1
and merge up.
>>> Is our macro `#define Z_EXPE
On Mon, Dec 18, 2017 at 4:11 PM, Sara Golemon wrote:
> On Mon, Dec 18, 2017 at 3:38 PM, Levi Morrison wrote:
>>> Thoughts? If I don't hear anything in a week, I'll just apply to 7.1
>>> and merge up.
>>>
>> Is our macro `#define Z_EXPECTED_TYPE_STR(id, str) str,` ever used? If
>> so there might
> I really think we ought to tackle covariant returns and contravariant
> parameters
My "algorithm" could be extended for contravariance:
Whenever a method has a parameter type hint that differs from the
parent type hint, autoload the class of the parent type hint.
I think I know too little abou
On Mon, Dec 18, 2017 at 3:38 PM, Levi Morrison wrote:
>> Thoughts? If I don't hear anything in a week, I'll just apply to 7.1
>> and merge up.
>>
> Is our macro `#define Z_EXPECTED_TYPE_STR(id, str) str,` ever used? If
> so there might be a change in perceived behavior because the first
> entry p
On Mon, Dec 18, 2017 at 11:52 AM, Andreas Hennings wrote:
>> I believe your algorithm fails on this simple setup:
>
> Another comment I want to make here:
> The examples you give each have multiple class declarations per file.
> I would personally not care much, if these result in fatal error.
> A
On Mon, Dec 18, 2017 at 12:43 PM, Sara Golemon wrote:
> This blog post came across my twitter today and it's certainly legit.
> https://cismon.net/2017/12/18/Fast-ZPP-s-Incompatibility-with-CPP/
>
> I tossed together this quick and dirty fix (and tested it with a
> simple C++ extension), but I wan
This blog post came across my twitter today and it's certainly legit.
https://cismon.net/2017/12/18/Fast-ZPP-s-Incompatibility-with-CPP/
I tossed together this quick and dirty fix (and tested it with a
simple C++ extension), but I wanted to get a read on what branch folks
think it should be applie
> I believe your algorithm fails on this simple setup:
Another comment I want to make here:
The examples you give each have multiple class declarations per file.
I would personally not care much, if these result in fatal error.
All of this code used to be illegal until now (because no covariance
s
Ok, I think I missed the circularity aspect in your examples.
Inheritance by itself is never circular.
However, return types can make this entire thing circular.
So the problem would be if we try to autoload the same thing that is
currently in the process of being being defined.
Maybe we could ge
Let me address the simple example first.
On 18 December 2017 at 15:45, Levi Morrison wrote:
>
> I believe your algorithm fails on this simple setup:
>
>
> interface A {
> function foo(): X;
> }
>
> interface B extends A {
> function foo(): Y;
> }
>
> interface X {
> function bar(): A
On Mon, Dec 18, 2017 at 5:18 AM, Andreas Hennings wrote:
> There were discussions about covariance and contravariance in the past.
> https://externals.io/message/98085#98105
> Unfortunately I was not subscribed back then, so I cannot respond to anything.
> So, here it goes again.
>
> WIth co- and
There were discussions about covariance and contravariance in the past.
https://externals.io/message/98085#98105
Unfortunately I was not subscribed back then, so I cannot respond to anything.
So, here it goes again.
WIth co- and contravariance, the following would be possible:
- contravariance.php
17 matches
Mail list logo
