[RFC][Vote] Typed Properties View as Markdown

Morning Dmitry,

> I suppose it should emit notice and return NULL.

Yes, as untyped properties do (they would also invoke magic for unset,

but defined property).

> I'll change this as well (in an hour).

Thanks ...

Nullable property support was missing from the implementation,

completely, because it wasn't merged at the time, but I did mention it
would be added.

It seems like we are changing details that should have been mentioned,

we're not in some cases, just clarifying them ... but I admit it's
clarification that should have been included in the RFC in some cases.

I would like to know what others think about halting the vote, and

reopening in a few days when we have finalized the implementation, and
possibly put some finishing touches on the RFC.

If a few people want that to happen, happy to do it ... personally, I

don't think we've deviated from the RFC.

Cheers
Joe

Morning Dmitry,

I made this check(s) to be invariant. You may like to do this
differently...

I think this is what everyone expects, isn't it ?

I did omit to mention that part ...

RFC doesn't define how uninitialized nullable typed properties should
behave.

It does:

Nullable typed properties will not raise an exception when accessed
before initialization.

It's the only bold text in the document :)

It seems correct to me; We raise uninitialized exceptions to prohibit
the return of null to user land, for nullable properties we don't need to
do that.

It does mean that ?int $foo; has an implicit default value of null, but
I can't see anything wrong with that, for a nullable property.

OK. This is the same that I like. I'll change implementation accordingly.
But what should unset() do?
Currently it makes property uninitialized and then it can't accessed.
I suppose it should emit notice and return NULL.
I'll change this as well (in an hour).

Thanks. Dmitry.

I'm open to being persuaded that is wrong.

I will review comments and current patch this morning ...

Cheers
Joe

Morning Dmitry,

There's no section for nullables, but there is mention of them,
specifically in relation to your query:

While parameters allow null to be accepted as the default value,
null is only a valid value for nullable properties.

Is there something wrong with that rule ?

It's OK. This just should be defined and it's defined in RFC (I missed)

Having explicit nullability means the declaration tells you all you
need to know, all the time.

Being able to set null any typed property means you can never be sure
of the type; You can't tell by looking at the declaration what type the
variable will be because anything is allowed to set it null.

We waited for explicit nullability to avoid this.

You'll have to have a really good reason for me to change that rule :)

Inheritance rules for typed nullable properties are also missed.

That's true, but shouldn't they use the same rules as nullable
parameters, will discussion change how they should work ?

I made this check(s) to be invariant. You may like to do this
differently...
It's better to define this in RFC, check implementation and add tests.

but still have unsolved problems.

If you have discussed these somewhere, can you send/show the
transcript ? (I missed all comms after yesterday morning, due to illness).

We are working with Bob, trying to improve the patch. I added new tests
fixing the problems, and also added few comments o github.

If it emerges that the RFC needs to be modified heavily, then I'm
happy to stop the voting.

RFC doesn't define how uninitialized nullable typed properties should
behave.

class C {
public $a;
public int $b;
public ?int $c;
}
$obj = new C;
var_dump($obj->a); // NULL
var_dump($obj->b); // throw Error("")
var_dump($obj->c); // first or second??? (currently throw Error("")).
$obj->$a = null;
$obj->$b = null; // throw Error("")
$obj->$c = null;
var_dump($obj->a); // NULL
var_dump($obj->b); // throw Error("")
var_dump($obj->c); // NULL
unset($obj->$a);
unset($obj->$b);
unset($obj->$c);
var_dump($obj->a); // notice + NULL
var_dump($obj->b); // throw Error("")
var_dump($obj->c); // first or second??? (currently throw Error("")).

This should be defined.

But, so far, we haven't actually deviated from the RFC, only changed
implementation details that are not part of the design of the feature.

I'm not so sure.
Anyway, I hope you are better and we will able to speak today or tomorrow.

Thanks. Dmitry.

Sorry if it seems like I'm missing information, I don't know what you
and Bob found out yet ...

I super appreciate you guys working on it, obviously. Thanks for that
:)

Cheers
Joe

On Tue, May 24, 2016 at 8:04 PM, Dmitry Stogov < dmitry@zend.com
dmitry@zend.com> wrote:

Hi Joe,

I've add implementation for nullable typed properties (as they fit into
the patch design), but RFC missed any description of nullable properties.
See tests Zend/tests/type_declarations/typed_properties_047.phpt,
Zend/tests/type_declarations/typed_properties_048.phpt,
Zend/tests/type_declarations/typed_properties_049.phpt

I'm not sure, if this is what the voters expect. At least I don't like
the facts that "?int $foo;" declares uninitialized property; "?int $foo =
NULL" may be unset() and became uninitialized; and it's an open question if
"int $foo = NULL;" should be supported as nullable. Inheritance rules for
typed nullable properties are also missed.

Personally, I think the RFC was moved into voting state too early
(without good enough implementation, and with missing topics).
The current implementation is better (performance penalty reduced to
~2%), but still have unsolved problems.

May be it's better to cancel voting, solve problems, finish the
implementation and add missing questions into RFC...
I'm going to help with implementation in any case, but we should agree
on what we are doing.

Thanks. Dmitry.

---

From: Joe Watkins < pthreads@pthreads.orgpthreads@pthreads.org>
Sent: Friday, May 20, 2016 9:05:34 AM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Morning internals,

Since we have our answer on nullable types, typed properties can now

go
to vote.

https://wiki.php.net/rfc/typed-properties#vote

Note that, support for nullability as RFC'd will be merged when the

implementation for nullable_types is merged into master.

Please participate.

Cheers
Joe

Morning Nikita,

That's pretty persuasive ...

Dmitry, what are your thoughts on those points ?

Cheers
Joe

On Wed, May 25, 2016 at 10:30 AM, Joe Watkins pthreads@pthreads.org
wrote:

Morning Dmitry,

I made this check(s) to be invariant. You may like to do this
differently...

I think this is what everyone expects, isn't it ?

I did omit to mention that part ...

RFC doesn't define how uninitialized nullable typed properties should
behave.

It does:

Nullable typed properties will not raise an exception when accessed
before initialization.

I don't agree with this choice, for three reasons:

a) This unnecessarily restricts what can be expressed in the type system.
With these semantics it will no longer be possible to express that a
property should be nullable, but have no default value. This situation is
not uncommon in practice, in particular anytime you have a nullable
constructor argument, you will want the corresponding property to be
nullable without a default, to ensure that it is explicitly initialized.

b) This directly contradicts the meaning of ?Type for parameters. For
parameters ?Type means that it's a nullable parameter without a default
value. That's the very thing that distinguishes it from the Type $prop =
null syntax. And now ?Type for properties should mean the exact opposite?

c) If you view this in a larger scope of union types, this special case
becomes even more weird. Why does the particular union Type|null get
special treatment, while all other unions don't? Or is it actually not
specific to "null", but to single value types? E.g. if we also allowed
Type|false, would that also receive an implicit false default value? What
about the type null|false? Does that get an implicit default, and if so,
which? I realize this is not quite in scope for type properties, but the
further evolution of the type system should be kept in mind.

Please keep things consistent: If there is not default, there is no
default.

Nikita

Hi,

Nikita Popov wrote:

> *Nullable typed properties will not raise an exception when accessed

before initialization.*

I don't agree with this choice, for three reasons:

a) This unnecessarily restricts what can be expressed in the type system.
With these semantics it will no longer be possible to express that a
property should be nullable, but have no default value. This situation is
not uncommon in practice, in particular anytime you have a nullable
constructor argument, you will want the corresponding property to be
nullable without a default, to ensure that it is explicitly initialized.

I agree with you here. In some cases, there are three potential
meaningful states for a property:

• uninitialised - the constructor (or indeed, other code) is yet to set it
• null - the property is left intentionally empty
• some other value - the property is intentionally given a value

A simple example might be a Lisp-style linked list cell:

 class LinkedList
 {
     public int $head;
     public ?LinkedList $tail;
 }

In a properly initialised LinkedList, the $head is some value, and the
$tail is either another linked list (the remainder of the list), or null
(we're at the end of the list).

Before the LinkedList is initialised, ideally both properties would be
undefined. That way, if we make a mistake and fail to explicitly set
either in our code, PHP will give us an error message.

However, the currently proposed behaviour would mean that this will only
happen for $head, and PHP will fill in null for $tail for us. Notice
that in this class, we aren't using null to mean a property that hasn't
yet been set. Instead, we're using it to mean a property that's been
deliberately left unfilled. So PHP has assumed for us that if we forget
to set $tail, the remainder of the list is empty. Yet PHP assumed that
if we forget to set $head, that's a mistake and must produce an error.
This inconsistency of assumptions is unhelpful, and I don't see how this
follows from the types I declared.

I don't understand why nullable properties have to behave differently
here, anyway. Doesn't it add complexity to the implementation to handle
them differently from non-nullable typed properties? Doesn't it
introduce inconsistency to assume a default value for nullable typed
properties, but not for non-nullable ones?

b) This directly contradicts the meaning of ?Type for parameters. For
parameters ?Type means that it's a nullable parameter without a default
value. That's the very thing that distinguishes it from the Type $prop =
null syntax. And now ?Type for properties should mean the exact opposite?

Given typed properties look much like typed parameters, it would be
reasonable for users to expect that they behave the same, so this is a
good point.

c) If you view this in a larger scope of union types, this special case
becomes even more weird. Why does the particular union Type|null get
special treatment, while all other unions don't? Or is it actually not
specific to "null", but to single value types? E.g. if we also allowed
Type|false, would that also receive an implicit false default value? What
about the type null|false? Does that get an implicit default, and if so,
which? I realize this is not quite in scope for type properties, but the
further evolution of the type system should be kept in mind.

This bothers me also.

Thanks!

Andrea Faulds
https://ajf.me/

On Wed, May 25, 2016 at 10:30 AM, Joe Watkins pthreads@pthreads.org
wrote:

Morning Dmitry,

I made this check(s) to be invariant. You may like to do this
differently...

I think this is what everyone expects, isn't it ?

I did omit to mention that part ...

RFC doesn't define how uninitialized nullable typed properties
should
behave.

It does:

Nullable typed properties will not raise an exception when accessed
before initialization.

I don't agree with this choice, for three reasons:

a) This unnecessarily restricts what can be expressed in the type system.
With these semantics it will no longer be possible to express that a
property should be nullable, but have no default value. This situation is
not uncommon in practice, in particular anytime you have a nullable
constructor argument, you will want the corresponding property to be
nullable without a default, to ensure that it is explicitly initialized.

I disagree here. Properties are always null by default. The current patch
disallows
access to uninitialized variables only if they're not nullable, since null
isn't a valid value then.

I don't think having to explicitly set them to null is the think we want.
And it's not what I'd expect given the current system.

b) This directly contradicts the meaning of ?Type for parameters. For
parameters ?Type means that it's a nullable parameter without a default
value. That's the very thing that distinguishes it from the Type $prop =
null syntax. And now ?Type for properties should mean the exact opposite?

These have always been different. private $foo has always been null by
default,
while function($foo) doesn't have a default value.

c) If you view this in a larger scope of union types, this special case
becomes even more weird. Why does the particular union Type|null get
special treatment, while all other unions don't? Or is it actually not
specific to "null", but to single value types? E.g. if we also allowed
Type|false, would that also receive an implicit false default value? What
about the type null|false? Does that get an implicit default, and if so,
which? I realize this is not quite in scope for type properties, but the
further evolution of the type system should be kept in mind.

I think this is something unions should address. I'm personally still not a
fan of union types,
as they try to solve the wrong problem, mostly things like array not being
instance of Traversable.

Regards, Niklas

Please keep things consistent: If there is not default, there is no
default.

Nikita

Morning Dmitry,

I made this check(s) to be invariant. You may like to do this
differently...

I think this is what everyone expects, isn't it ?

I did omit to mention that part ...

RFC doesn't define how uninitialized nullable typed properties should
behave.

It does:

Nullable typed properties will not raise an exception when accessed
before initialization.

I don't agree with this choice, for three reasons:

a) This unnecessarily restricts what can be expressed in the type system.
With these semantics it will no longer be possible to express that a
property should be nullable, but have no default value. This situation is
not uncommon in practice, in particular anytime you have a nullable
constructor argument, you will want the corresponding property to be
nullable without a default, to ensure that it is explicitly initialized.

b) This directly contradicts the meaning of ?Type for parameters. For
parameters ?Type means that it's a nullable parameter without a default
value. That's the very thing that distinguishes it from the Type $prop =
null syntax. And now ?Type for properties should mean the exact opposite?

c) If you view this in a larger scope of union types, this special case
becomes even more weird. Why does the particular union Type|null get
special treatment, while all other unions don't? Or is it actually not
specific to "null", but to single value types? E.g. if we also allowed
Type|false, would that also receive an implicit false default value? What
about the type null|false? Does that get an implicit default, and if so,
which? I realize this is not quite in scope for type properties, but the
further evolution of the type system should be kept in mind.

Please keep things consistent: If there is not default, there is no default.

Object properties being in a uninitialized state is unfamiliar in
current PHP practice. We are accustomed to not worrying about an
"uninitialized error" when we read a property. We are assured to get
either null or whatever was last written to the property.

I suspect this unfamiliarity lies behind some people's preference for an
implicit initial null value of a nullable typed property.

But I'm inclined to agree with Nikita that the following should be
different:

public ?Client $mark;
public ?Client $mark = null;

... and that the difference should be coherent with that between:

function con(?Client $mark) {}
function con(?Client $mark = null) {}

... which is that you must give $mark value in the first and you don't
need to in the second because it has an explicit default. We are
more-or-less accustomed already to the difference between:

function con(Client $mark) {}
function con(Client $mark = null) {}

... so I think your consistency argument is good.

Moreover, the "good old" implicit initial null for untyped properties
(i.e. that public $foo; means public $foo = null;) is just a lazy
shortcut that I wouldn't defend except for BC, which isn't an issue here.

Tom