I thought about a different approach :)

- not-nullable typed properties must be explicitly initialized (or should be 
initialized implicitly by corresponding types, e.g. "int" should get default 
value int(0). ...)

- nullable typed properties may be implicitly initialized by NULL (like untyped 
properties now).

- unset() of typed properties should not be allowed


This would allow to eliminate few weird run-time checks in VM and allow the 
most efficient usage of type information in Optimizar and JIT.


Thanks. Dmitry.

________________________________
From: Joe Watkins <pthre...@pthreads.org>
Sent: Wednesday, May 25, 2016 4:22:02 PM
To: Nikita Popov
Cc: Dmitry Stogov; PHP internals; Phil Sturgeon; Bob Weinand
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning Nikita,

    That's pretty persuasive ...

    Dmitry, what are your thoughts on those points ?

Cheers
Joe

On Wed, May 25, 2016 at 2:03 PM, Nikita Popov 
<nikita....@gmail.com<mailto:nikita....@gmail.com>> wrote:
On Wed, May 25, 2016 at 10:30 AM, Joe Watkins 
<pthre...@pthreads.org<mailto:pthre...@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

Reply via email to