Morning Dmitry,
> If we use one rule for arguments, why should we invent others.
Properties are going to be nullable only if you explicitly initialise them
with NULL.
We didn't really invent anything, you are comparing them to parameters, but
not return values ... strangely ...
Return values are not implicitly nullable, and a few people have been
designing RFC's to tackle this issue by introducing expicitly nullable
types, or union types.
This code:
class Foo {
public function getBar() : int {
return $this->bar;
}
private $bar;
}
$foo = new Foo();
var_dump($foo->getBar());
Should provide the same guarantees that this code does:
class Foo {
public int $bar;
}
$foo = new Foo();
var_dump($foo->bar);
In either case, an exception will be raised.
Given the following code:
<?php
class Foo {
public function getBar() : int {
return $this->bar;
}
private $bar = null;
}
$foo = new Foo();
$foo->getBar();
We throw an exception, because null is not a valid int, and types are not
implicitly nullable, even if parameters, and untyped properties are ...
<?php
class Foo {
public int $bar = null;
}
$foo = new Foo();
var_dump($foo->bar);
Again, we raise an error, but much earlier this time ( we should all agree
earlier is better).
What we have done is apply existing rules in a way that makes sense, the
only thing we invented is the rule that null is never a valid value.
We invented that rule first to make return types and property types
consistent, and, because without it, the guarantee that you will always get
a variable of the correct type is gone, and your code is filled with null
checks.
There is value in nullable types, but they must only be explicitly
nullable, in exactly the same way that return values should be, and we
simply don't have syntax to support that at the moment.
I hope this makes some of these decisions clearer ...
Cheers
Joe
On Wed, Mar 30, 2016 at 7:22 AM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>
> On 03/30/2016 08:13 AM, Joe Watkins wrote:
>
>> Morning Dmitry,
>>
>> So, I quickly reviewed the RFC and patch.
>>
>> Static properties, and mixed declarations, are now explained in the
>> RFC.
>>
> Thanks. I'm not agree with decisions, but RFC is more complete now.
> It would be great to have "static" typed properties at the same time, but
> this may be more difficult.
> Mixed declarations decision looks wrong to me, but right to some others.
> From implementation point of view, it's not a big problem to change it.
>
>
>> I made a couple of changes to the fetch_obj_w stuff, I'd be grateful
>> if
>> you could review that ... I didn't think I had got all possible
>> combinations, should be bit better, and drier ...
>>
>> The overflow related stuff, I'll fix and explain in the RFC, but I'll
>> let you have a go at perf stuff, and other outstanding things now ...
>>
>> */me leaves patch alone*
>>
>
> OK. I'll try to do something today.
>
> Thanks. Dmitry.
>
>
>
>> Cheers
>> Joe
>>
>> On Wed, Mar 30, 2016 at 5:26 AM, Joe Watkins <pthre...@pthreads.org>
>> wrote:
>>
>> Morning Pieere, Dmitry, all ...
>>>
>>> Actually it's not so simple ... for object properties we have ASSIGN_OBJ
>>> opcode, but we don't have a special opcode for static properties, and
>>> ASSIGN doesn't have any information about where the var came from, and
>>> nor
>>> should it have that information ...
>>>
>>> I'm going to stick the original decision, static properties don't belong
>>> until typed variables are a thing ...
>>>
>>> Cheers
>>> Joe
>>>
>>> On Wed, Mar 30, 2016 at 4:57 AM, Pierre Joye <pierre....@gmail.com>
>>> wrote:
>>>
>>> On Mar 30, 2016 10:17 AM, "Joe Watkins" <pthre...@pthreads.org> wrote:
>>>>
>>>>> Morning Dmitry,
>>>>>
>>>>> 1) static typed properties are prohibited. why?
>>>>>>
>>>>> Feels like that's a separate feature, static properties are as good as
>>>>> makes no difference, global variables.
>>>>>
>>>>> Instance properties, the engine has good control over their
>>>>>
>>>> manipulation,
>>>>
>>>>> for static properties it doesn't, it's not impossible, but feels
>>>>>
>>>> separate.
>>>>
>>>> Internally different but from users perspective it is the same (a class
>>>> property). It would be nice to support that at the same time to avoid
>>>> confusion.
>>>>
>>>>
>>>
>
