On 03/30/2016 10:50 AM, Joe Watkins wrote:
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 types don't have default values :)
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.
I know. Missing the ability to mix objects with null is a big problem,
but it's unrelated.
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).
class Foo {
public $bar;
function foo (int $bar = null) { // <-- this already works fine
$this->bar = $bar;
}
}
class Foo {
public int $bar = null; // <- with your approach, this is prohibited
function foo (int $bar = null) {
$this->bar = $bar; // <-- this won't work
}
}
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.
Both views may make sense.
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.
Nobody require to use "nullable" types. It's just a feature that we
already may use for parameters, and miss for return values yet.
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.
Why can't we reuse the existing explicit syntax for parameters?
I hope this makes some of these decisions clearer ...
One more thought about implicit initialization values. (int(0) for int
instead of IS_UNDEF).
I'm not sure if this RFC is going to be accepted yet, but lets think we
will also implement type hinting for arrays.
e.g. "array<int,int> $a[40];" would create a packed array of integers
with 40 elements.
I would prefer to have all elements initialized by int(0) instead of
IS_UNDEF.
In this case we won't have to use zvals (and Buckets) for elements at
all, and will able to narrow this type to native C array "long a[40];"
This would safe 3/4 of memory required for array, and improve data locality.
Actually, this is exactly the same for properties.
Thanks. Dmitry.
Cheers
Joe
On Wed, Mar 30, 2016 at 7:22 AM, Dmitry Stogov <dmi...@zend.com
<mailto: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 <mailto: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 <mailto:pierre....@gmail.com>> wrote:
On Mar 30, 2016 10:17 AM, "Joe Watkins"
<pthre...@pthreads.org <mailto: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.
