Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

I would really appreciate constructive feedback on this RFC, with a
few areas especially:

1. How scared are we that integers can be expanded to floats on runtime?

First, this looks awesome, Phil!

After reading through it, I think we can consult with function return
types:

function blah() : int {
return 55.5;
}

var_dump(blah());

Will return 55. It's a little different with properties, but what are
your thoughts on this runtime conversion?

Hey Will,

Sure you'll see 55 in weak mode, but in strict mode you'll see 55.5.

I don't really want to delve too much into how return types work in
this RFC, because it doesn't feel entirely relevant.

3. Weak vs Strict. Right now this is entirely strict, with no
   declare() to change mode. Reasons for this vary, from various sources,
   but include "Not sure how to implement it" and "Well people should not
   be using properties as part of their public API".

As much as I didn't (and don't) particularly like the declare()
switch, it doesn't seem like a good idea to me to introduce a typing
feature a year after it that doesn't use it, but has its own mode of
operation. To me, it seems like this:

class Foo {
public int $num;
}

(new Foo)->num = $bar;

Should behave the same as the setter equivalent does today:

class Foo {
public $num;
public function setNum(int $num) { $this->num = $num; }
}

(new Foo)->setNum($num);

That is: if $num either can't be coerced to an integer (in weak mode)
or isn't itself an integer (in strict mode), a TypeError should be
thrown.

We could argue about whether properties should be part of a public
API, but the reality is that a class declaring a public property
effectively is making it part of its API, whether you or I think it's
a good idea or not. :)

We'll have a nice, orderly, constructive conversation about this RFC,
and improve the patch as you all provide feedback.

Let me know what you think folks!

The above leads into another question I'm interested in your (and
Joe's) general thoughts on: how do you think this would potentially
intersect with a property getter/setter RFC in the future? Might be
good fodder for the future scope section!

Yeah, I'll add a note about that. :)

Finally, while the RFC shows invalid assignments generating fatal
errors, the patch seems like it throws TypeError exceptions instead.
Which one is the desired behaviour? (I'd prefer TypeError, personally,
for consistency with function type declarations today.)

Adam

If you put them in the class definition you'll get a fatal error from
the compiler (might change) and at runtime you get an Error. Different
things for different things. :)

Hey, thank you both for investing your time :-)
Property types are definitely interesting.

Am 16.03.2016 um 17:36 schrieb Phil Sturgeon pjsturgeon@gmail.com:

Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

I would really appreciate constructive feedback on this RFC, with a
few areas especially:

1. How scared are we that integers can be expanded to floats on runtime?

This IMHO is quite necessary, for the same reasons why we even allow int
to float widening with strict return types.

class foo {
float $bar;
function __construct(int $x) {
assert($x > 0);
$this->bar = 10 / $x;
}
}

This is perfectly innocuous, but will fail for values 1, 2, 5 and 10, if
we don't allow widening.
Depending on the values it might also be not caught in testing.

2. This whole temporary nullability situation, where unset properties
   will error on attempted usage if not set. Should they instead error
   after the constructor has been called if they are still not holding a
   value?

Erroring when using the unset property is the way to go.

The example from the RFC is showing exactly why...

class Foo {
public int $foo;
}
$foo = new Foo();
echo $foo->foo; // Patch currently errors here

With one property, not so much an issue, we could force a constructor.
But with 20 properties, definitely an issue.

If we'd error after constructor call, there are also other complications…

class Foo {
public int $bar;
function __construct() {
global $foo;
$foo = $this;
}
}
try {
new Foo;
} catch (Error $e) {}
var_dump($foo->bar); // not set, but instance is referenced

Sure, we could find ways to circumvent that and change the class to
totally non-functional and making every usage of it throw an Error, but it
isn't quite elegant.

3. Weak vs Strict. Right now this is entirely strict, with no
   declare() to change mode. Reasons for this vary, from various sources,
   but include "Not sure how to implement it" and "Well people should not
   be using properties as part of their public API".

Help on 3 would be appreciated.

Now, if we already have int to float widening (which I recommend), we
anyway need to do certain checks.
At that point we can just as well add weak typing, because, why not?

We do not have an exceptional handling for return types (which are even
more subject to be strict-only as it is function-local — properties may be
public). And so we shouldn't have either for property types.

Thus, my recommendation is to be consistent regarding strict and weak
typing regarding argument and return types.

Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
rather common rhetoric. Strict Type Hinting might have been seen as a
battleground for fans of strict and fans of weak to fight through a
keyboard, but this RFC will not be the repeat.

We'll have a nice, orderly, constructive conversation about this RFC,
and improve the patch as you all provide feedback.

Let me know what you think folks!

Thanks,
Bob

I'm not 100% convinced that we need this now we have full type hint support
for parameters and return types; but it does have potential to remove
boiler plate for public properties. For point 2 nullable properties, how
about some syntax which allows for a property to be null, or for it to be a
specific type. I'd suggest a null assignment to fall in line with parameter
type hints eg:

class Foo {
protected int $bar = null; //can be null
private stdClass $baz; //can't be null
}

Am 16.03.2016 um 18:39 schrieb Johannes Schlüter johannes@schlueters.de:

Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

I'm no fan of all this typing business, but that's a lost case. Anyways:
What about references? (yeah, references should die, but currently they
still exist)

What's expected here:

class A {
public int $i;
}

$a = new A();
$r = &$a->i;
$r = "foobar";

johannes

The patch currently prevents that.
It prevents all creation of references to properties.

The reason is technical:
We'd basically need typed zvals.
Or add some sort of write callback to typed references.

If you have a clean solution to these issues, you're more than welcome to contribute here.

Bob

On Wed, Mar 16, 2016 at 1:39 PM, Johannes Schlüter
johannes@schlueters.de wrote:

Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

I'm no fan of all this typing business, but that's a lost case. Anyways:
What about references? (yeah, references should die, but currently they
still exist)

What's expected here:

class A {
public int $i;
}

$a = new A();
$r = &$a->i;
$r = "foobar";

johannes

Hey there!

I put your code into 3v4l so you could see what would happen:

https://3v4l.org/taC8D

Fatal error: Uncaught TypeError: Typed property A::$i must not be referenced

Is that what you expect? If not, what would you expect?

On Wed, Mar 16, 2016 at 12:50 PM, Larry Garfield larry@garfieldtech.com
wrote:

2. This whole temporary nullability situation, where unset properties
   will error on attempted usage if not set. Should they instead error
   after the constructor has been called if they are still not holding a
   value?

I fall back to a statement I made in a blog post a while back:

http://www.garfieldtech.com/blog/empty-return-values

" But consider what you could do instead that would not force me to throw
is_null() around my code, because throwing is_null() around my code makes
me sad. NULL should be the return value of last resort, because it means
nothing. (Literally.)"

Allowing default-null on properties means that as someone using that
property, I have two options:

1. Throw a lot of is_null() calls around my code.
2. Assume that whoever initialized the code provided a value by the time
   initialization is done and skip those extra checks.

Insert that old adage about what happens when you assume.

End-of-constructor checks seem like a good approach; they have to be
uninitialized at some point when new is called initially, but they should
be guaranteed set as soon as possible. End of the constructor is "as soon
as possible", and I think reasonably static-analysis-catchable. (Meaning
my IDE can yell at me appropriately.)

That removes is_null() calls from the rest of my codebase, which is a good
thing.

I'm not sure I like the "after contructor" because that's not necessarily
when the object is finished being initialized. Consider this:

abstract class Contract
{
private function __construct() {}

public static function fromArray(array $aProps) : Contract
{
    $s = new static();
    foreach ($aProps as $k => $v) {
        if (property_exists(static::class, $k)) {
            $s->$k = $v;
        }
    }

    return $s;
}

}

class User extends Contract {
public int $id;
public string $name;
}

$user = User::fromArray(['id' => 123, 'name' => 'derokorian']);

In this example, the constructor finishes but the properties still are not
initialized at time of finishing. This is a pretty common pattern as well.

Hi all,

Am 16.03.2016 um 21:29 schrieb Fleshgrinder:

Another more complicated user case would be mysqli_fetch_object that
populates the properties with values from a storage but values that
should become something specific and strict at some point but are
initially populated as strings. Type coercion would be a nice thing here
but with strict checks afterwards.

I really don't like the special way mysqli and PDO use here.
Both should use the __set_state() magic method as would any userland code.
But that is a discussion for another thread ;-)

Greets
Dennis

Hi,

Fleshgrinder wrote:

2. This whole temporary nullability situation, where unset properties
   will error on attempted usage if not set. Should they instead error
   after the constructor has been called if they are still not holding a
   value?

I see a big problem with the erroring no matter when as others already
pointed out, e.g. together with named constructors (or factory methods
if you prefer that name) but also with lazy loading. I think that the
null value of properties during and after construction should simply be
ignored and left to the implementer. I know that it would be nice to
have 100% assurance that the property is always set but it would simply
result in rules that are too strict for various use cases. I mean,
aren't we trying to solve a problem that never was a problem here?

This is actually a problem for optimising PHP. If the compiler cannot be
sure a property's value actually matches its declared type, it can't
optimise operations on that property to remove a type check.

I also think it would be unintuitive if typed properties had some
exception where they don't obey the given type. If I ask for an integer,
then surely I should get an integer?

Another more complicated user case would be mysqli_fetch_object that
populates the properties with values from a storage but values that
should become something specific and strict at some point but are
initially populated as strings. Type coercion would be a nice thing here
but with strict checks afterwards. Note that this cannot be handled by
the extension due to user types:

 final class Bar {

     private string $data;

     public function __construct(string $data) {
         $this->data = $data;
     }

 }

 final class Foo {

     private Bar $bar;

     private function __construct() {
         if (isset($this->bar)) {
             $this->bar = new Bar($bar);
         }
     }

 }

 $mysqli_result->fetch_object(Foo::class);

It is correctly populated with a string and the constructor changes it
to the desired instance. All fine, but the strict type check would kill
everything here.

I think that the strict type checks should start with the first
userland assignment and at no other point in time. The correct
initialization of an object is up to the implementer as it always was.

This adds a loophole to property type checks which, as previously
mentioned, prevents us from performing optimisations. I also don't see
why internal functions should be treated specially here, given that
surely one could write userland code with the same needs as MySQLi? It
doesn't seem intuitive.

[...] how about some syntax which allows for a property to be null,
or for it to be a specific type. I'd suggest a null assignment to
fall in line with parameter type hints eg:

class Foo {
protected int $bar = null; //can be null
private stdClass $baz; //can't be null
}

This aligns nicely with the syntax that is present in PHP for arguments
since ages and it directly could solve the Nullable problem mentioned in
future scope.

We could certainly do this, but I'm not sure we should. Like for
arguments, this would mean that your default value must be null, and you
don't have to assign to it. But what if you want a different default
value? What if you want to require it be assigned to?

Adding a syntax form for nullable types (e.g. ?int or int|null)
would avoid these issues, and also solve the nullable return type issue.

3. Weak vs Strict. Right now this is entirely strict, with no
   declare() to change mode. Reasons for this vary, from various sources,
   but include "Not sure how to implement it" and "Well people should not
   be using properties as part of their public API".

An ini setting to control type checks and hints would be a nice thing to
have.

An INI setting to control type checks is impractical, because it would
affect all PHP code running in a given PHP interpreter. This means you
control not only the type checking mode of your own code, but also of
all the libraries you're using. Unless you never use other people's
code, using this INI setting would just break things.

Like the checked mode of Google's Dart language. Such a setting
could and should also allow to disable type checks altogether, like we
have it with assertions:

 strict_types = -1 ; NOOP
 strict_types = 0  ; PHP 5 Style
 strict_types = 1  ; PHP 7 Coercion Style
 strict_types = 2  ; PHP 7 Strict Style

Why would you want to disable type checks altogether? There might be a
small performance improvement, but you've removed important error
checking. What if something goes wrong at runtime?

Where 1 would be the default since the default should be for development
and people who hate strict types just throw that zero in their ini and
are fine to reuse any code out there while ignoring all property/scalar
type checks/hints.

This solves a problem which I don't believe exists. The system PHP 7 has
means that if you don't want to use strict types, they never affect you.

This would make the declare thingy pretty useless and I think it is
easier to understand. I thought that this approach was kind of weird
since its inception.

Yes, the declare() approach is unusual compared to other settings.
That's because it was designed so the choices your code makes doesn't
affect other code which uses it. In the Composer era, this matters,
because a lot of code your interpreter is running will not be written or
maintained by you.

Thanks.

--
Andrea Faulds
https://ajf.me/

Like the RFC :)

Could this be an opportunity to have default visibility for property's when
they are typed in a similar fashion like for functions? Meaning no
visibility
implies public and code below would work.
class A {
int $i=7;
function f() {
echo $this->i;
}
}
$a = new A();
$a->f();
echo $a->i;

Was inspired by discussion in "var" Deprecation thread.

Regards //Björn

I'd rather like to see this being package visible rather than public. Of
course, that would be yet another Java thingy and I am not trying to
jump on the bandwagon here.

First, I like the Class Friendship RFC because it is very explicit in
terms of giving access to your members. However, it fails to solve some
issues in API design because friendship is not inherited and it is
especially useless in a composer package world where the classes you
might define as a friend are not even available (example follows).

Second, I like the Private Class PR because it is very simple in hiding
a class. The fact that is is purely namespace based is however a problem
because one might want to have a class in a sub-namespace but still have
the ability to instantiate it. Also protected classes would be only
possible by restricting them from the current down to sub-namespaces
which is totally meh.

The introduction of a new package keyword to provide access modifiers
for more fine grained control could solve all of the above issues.

<?php
// Composer Package `fleshgrinder/best-cms-entity`

package fleshgrinder/entity;

namespace Fleshgrinder\Entity;

use DateTimeImmutable;

final public class Entity {

    int $id;

    string $name;

    DateTimeImmutable $created;

    DateTimeImmutable $changed;

    private function __construct() {}

    public function equals($other) {
        if ($other instanceof self) {
            return $this->id === $other->id
                || $this->name === $other->name;
        }
        return false;
    }

}

<?php
// Composer Package `fleshgrinder/best-cms-entity`

package fleshgrinder/entity;

namespace Fleshgrinder\Repo;

use Fleshgrinder\Entity\Entity;

public interface Repo {

    public function create(string $name): Entity:

}

<?php
// Composer Package `fleshgrinder/best-cms-in-memory-entity-repo`

package fleshgrinder/entity;

namespace Fleshgrinder\Repo;

use DateTimeImmutable;
use Fleshgrinder\Entity\Entity;

final public class InMemoryRepo implements Repo {

    private array $entities = [];

    public function create(string $name): Entity {
        $new = new Entity();
        $new->id = count($this->entities) + 1;
        $new->name = $name;
        $new->created = $new->changed = new DateTimeImmutable();

        foreach ($this->entities as $entity) {
            if ($entity->equals($new)) {
                throw new \Exception;
            }
        }

        $this->entities[] = $new;

        return clone $new;
    }

}

--
Richard "Fleshgrinder" Fussenegger

What about PDO's fetch-mode PDO::FETCH_CLASS? Apparently, it first fills in
properties and then calls the constructor. Seems unlikely that the new
behavior for uninitialized properties will cause a problem here, but
sometimes weird things happen. And this is another thing to check.
I also fully support Johannes Schlüter with the reference thing. Binding by
reference to a query, passing by reference to any sort of function might
happen here and there, and the developer will have to find workarounds in a
place which otherwise would be straighforward.

Having said that, I +1 the idea of typed properties (well, my internals
karma does not give much weight to this anyway ;-) ).

On Thu, Mar 17, 2016 at 9:11 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

On Wed, Mar 16, 2016 at 5:36 PM, Phil Sturgeon pjsturgeon@gmail.com
wrote:

Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

I would really appreciate constructive feedback on this RFC, with a
few areas especially:

1. How scared are we that integers can be expanded to floats on runtime?

2. This whole temporary nullability situation, where unset properties
   will error on attempted usage if not set. Should they instead error
   after the constructor has been called if they are still not holding a
   value?

3. Weak vs Strict. Right now this is entirely strict, with no
   declare() to change mode. Reasons for this vary, from various sources,
   but include "Not sure how to implement it" and "Well people should not
   be using properties as part of their public API".

Help on 3 would be appreciated.

Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
rather common rhetoric. Strict Type Hinting might have been seen as a
battleground for fans of strict and fans of weak to fight through a
keyboard, but this RFC will not be the repeat.

We'll have a nice, orderly, constructive conversation about this RFC,
and improve the patch as you all provide feedback.

Let me know what you think folks!

Thanks for the RFC. I love it.

Some points:

1. You should really try not to open any can of worms with regard to other
   already defined parts of the language:

• Assume type juggling is a given, use that exact same rules
• Assume strict/weak is a given, don't try to change this.
• Document how public int $var; works with regard to default type,
  explicitly define it outside the scope of nullable types and delegate
  decision forward to a potential RFC in that area.

Regarding your bullets then:

1. This point is outside the scope of this RFC, it might be relevant when
   we discuss changing type juggling to be more consistent.
2. This is propably the critical point of this RFC, I think given how
   public function foo(int $i) forces type juggling, typed properties should
   force juggling to. This must be after the constructor, because public
   stdClass $foo; would otherwise never work.
3. Weak vs strict: Outside of this RFC, assume that it is strict when
   declared, otherwise weak for consistency with the status quo.

--

--
Best regards,
Victor Bolshov

Hi,

I'd support borrowing the "?" nullable annotation from HackLang for

people who want a less strict behavior:

public ?string $name;

This means that $name can either be a string or the NULL value.

Or, do it like with parameter type hinting:

 public string $name = null;

Although I'm all for limiting NULL to only being the default value:

$this->name = null; // this should throw a TypeError

Cheers,
Andrey.

Quick update folks, the RFC patch now respects strict mode, so will be
weak by default and strict if enabled.

I'll update the RFC to reflect this soon, but I'm busy today and it
won't get done until tomorrow.

Also there is definitely no void keyword for properties.

We'll move onto working out default values and references shortly.
There are some great points in here, so let me get 0.3.0 of the RFC
out and we'll get onto that.

Hi,

Le 16/03/2016 17:36, Phil Sturgeon a écrit :

Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

Maybe you can add a reference to a discussion we had some months ago :
http://www.serverphorums.com/read.php?7,1296955. This was not exactly about
typed properties but it also concludes that enforcing type checks on every
write access requires typed zvals, which would be extremely powerful, but
also a very complex task (mostly for performance reasons).

Regards

François

To answer my own question: the entire RFC is a no-go in its current state.

That said, I have a few quite common use-cases that arise and that are a
bit problematic, both because they are hacks and because they are actually
used in large projects.

Specifically, I'm worried about two particular use-cases:

• unsetting properties
• by-ref property assignment

To clarify, un-setting properties allows us to hide properties completely,
loading them on a per-usage basis:

class Foo {
public int $bar;
public function __construct() {
unset($this->bar); // is this operation legal? For BC compliance,
I'd expect that to be the case
}
public function __get(string $name)
{
initialize_properties_here($this); // external thing connecting to
db, loading files, yadda yadda
}
}

var_dump((new Foo())->bar); // what happens here? can
initialize_properties_here actually assign a non-int to $bar? Will the
type safety still work?

See https://3v4l.org/bsHXH/rfc#tabs - unset() doesn't work, and that breaks
some basic PHP semantics that are covered by phpt tests, but just for the
case of typed properties.

The by-ref property assignment is a bit trickier, but can probably be
worked around with some overhead (re-assigning).
Here's what is going on:

class Foo {
public int $bar;
public function __construct() {
unset($this->bar);
}
public function __get(string $name)
{
$this->bar = 123; // default value
$props = ['bar' => & $this->bar]; // is this operation now
considered illegal?
initialize_properties_here($props); // external thing connecting
to db, loading files, yadda yadda
}
}

See https://3v4l.org/sKqYb/rfc#tabs - by-ref assignment is forcefully
disabled, and that breaks some more PHP semantics just for the case of
typed properties.

To sum it up, the RFC has one major problem: it focuses on the WHEN
assignments happen, rather than just checking WHAT is assigned.

I think the scope of the proposal needs to be reduced strictly to type
checking.
As it stands, this is too magic (and I do qu

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Morning Lee,

Phil is in a field somewhere, but I don't want to leave you hanging on for
an answer ... so ...

class Foo
{
public $bar;
public function __get($name)
{
return 123;
}
}

$foo = new Foo();
var_dump($foo->bar);

You should not expect __get to be called in this example code; __get is
only invoked when the property is undefined.

That's what unset does; It doesn't just destroy the value, but tells the
engine that the property is not declared (leaves it undef), which is what
results in the subsequent invocation of __get upon access to the unset
property.

Accessing the property before it was unset though, as it always did,
attempts to read the default value (null).

We haven't changed any of that ...

If $bar were typed, it would obviously be unacceptable to return anything
other than a value of the declared type upon access, so we must not allow
return to happen if there is no value on a typed property, because it's an
obvious violation.

Accessing a typed member before there is any possible chance the variable
was set is a programmer error - colloquially known as "use before
initialization" - a very common programming error, which we helpfully raise
an exception for.

Accessing a typed member after they were unset is another programming error

• "use after free" - again, we helpfully raise an exception.

In both of these circumstances, raising an exception is the only possible
action; Anything else really would constitute a change to the way objects
work, and or a violation of the type declared.

The most you can say about this, is that it's strange that the same
exception is raised for both cases, which we're aware of; Right now, it's
impossible to distinguish between the two states.

The things you can be sure of:

• If you get a value from an access of a typed property, it is the
  correct type.
• If you get exceptions, you have logical errors in your code.

Cheers
Joe

Hi all,

first up, major thanks to both Joe and Phil for putting this together.
I'm fully behind the concept of typed properties and think it would be a
great feature to have in the language.

I have a few points I'd like to make on the current implementation being
proposed.

1. There's an issue with the way the __get magic method works. I understand
   this has been introduced from allowing unset on typed properties (because
   of the reasons Marco mentioned previously), however it's still something I
   feel needs addressing:

class Foo
{
public int $bar;
public function __get($name)
{
return 123;
}
}

$foo = new Foo();
unset($foo->bar);
var_dump($foo->bar); // int(123)

$foo = new Foo();
var_dump($foo->bar); // Fatal error: Uncaught TypeError: Typed property
Foo::$bar must not be accessed before initialisation

I'd consider the fact that var_dump($foo->bar); produces different things
here a bug. They're both unset/uninitialised and should produce the same
result. Which in my opinion should be "int(123)", but i'll get onto that in
a bit.

2. Having a guarantee that a variable is of a certain type has a ton of
   benefits, mostly that you don't have to add defensive code to check its
   type. As Larry pointed out, littering your code based with !is_null() is
   not a nice thing to have to do.

Unfortunately typed variables will at some point be uninitialised. you
can't really force the developer to set them (either at construct or later)
as this is something that should in my opinion always belong at
implementation and not baked in/forced at the language level. With this in
mind, handling uninitialised state will always be a thing that needs to be
done. We can't really guarantee that the property was set up properly, or
start to return a default value of said type.

Further to this, and the fact that the ability to unset typed properties
has been reintroduced it now becomes possible to initialise a property,
have it unset and get TypeError's on subsequent access (where no __get() is
provided). So even after initialisation we can never be 100% sure a
property hasn't been destroyed and contains the type you'd expect.

As it doesn't appear there's any way we can actually provide this
guarantee. I'd suggest removing TypeError's on access as it's superfluous.
This would then solve my first point as the magic method would be called as
expected. I know this isn't ideal, but the type check on set is still very
powerful and still provides a guarantee that you have either an
uninitialised property, or a one of a type you'd expect.

3. One final small point; it would be great if we could also have typed
   properties outside the scope of a class. Not a show stopper by any means,
   but certainly a nice to have.

That's all. Again thanks so much for putting this together.

Lee

/@leedavis81

On Wed, Mar 16, 2016 at 4:36 PM, Phil Sturgeon pjsturgeon@gmail.com
wrote:

Hello everyone,

I have completed the draft for an RFC, to add Typed Properties. The
patch has been written by the one and only Joe Watkins.

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

I would really appreciate constructive feedback on this RFC, with a
few areas especially:

1. How scared are we that integers can be expanded to floats on runtime?

2. This whole temporary nullability situation, where unset properties
   will error on attempted usage if not set. Should they instead error
   after the constructor has been called if they are still not holding a
   value?

3. Weak vs Strict. Right now this is entirely strict, with no
   declare() to change mode. Reasons for this vary, from various sources,
   but include "Not sure how to implement it" and "Well people should not
   be using properties as part of their public API".

Help on 3 would be appreciated.

Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
rather common rhetoric. Strict Type Hinting might have been seen as a
battleground for fans of strict and fans of weak to fight through a
keyboard, but this RFC will not be the repeat.

We'll have a nice, orderly, constructive conversation about this RFC,
and improve the patch as you all provide feedback.

Let me know what you think folks!

2. The handling of multiple properties in the same declaration statement
   is inconsistent.

    public int $bar, string $qux; // this works
   
    public int $bar, $qux; //this emits error: Untyped property
   

A::$qux must not be mixed with typed properties

It's better to allow type only before first property in the list and
apply them to all of them (like C, Java and others).
Is this just an implementation issue?

I'm actually glad this is prevented because it's confusing. Is $qux
typed or untyped?

I think its very obviously typed int. This would allow you to list a bunch
of things of the same type in a single declaration, meaning only a single
visibility and type for the line, instead of having to repeat the type for
each property (whilst not having to repeat the visibility, this feels
inconsistent).

public string $firstName, $middleInitial, $lastName, $nickName;

vs

public string $firstName, string $middleInitial, string $lastName, string
$nickName;

I like the first much better personally. The second feels inconsistent, why
would the visibility carry to all properties but not the type?

Actually, static properties are probably simpler than I thought ... I'm
still not sure about them though ...

I'd like to hear what others thing about static properties having types ...

Cheers
Joe

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.

2. The handling of multiple properties in the same declaration statement
   is inconsistent.

This feels consistent to me .. in other languages where the type is
required, it makes sense to assume the type is implied.

In a language where the type is optional, public int $foo, $bar; feels
ambiguous to me.

3. We already have nullable arguments without any special syntax. We
   should reuse the similar approach for properties.

Making properties implicitly nullable defeats the object of trying to
provide type safety.

Null is never a valid value for a typed property, if it were, you would
never be sure of the type of variable you are getting, and would have to
litter your code with is_null checks.

I think it might be better to implicitly initialize them according to
type (if default value is not provided): bool by false, int by 0, double by
0.0, string by "" (interned), array by [] (immutable), objects by NULL
(always nullable).

Definitely not, lying about the default value isn't a good idea.

There are times when 0 is as valid as 1, or any other value for an int.

If you have declared that you know the type of the property, and you write
code that accesses that property before there is any possible chance you
have set the property, that's a programming error.

We should not hide that error with a default value, or by allowing the
engine to return null.

We can't change property_info->type_ce for internal properties, because
they are shared between threads.

I'm not sure what to do about that ... will think ...

6. and 7) and 8) just sound like bugs ... will look at those ...

7. I always intended to leave that to you :)

Cheers
Joe

Hi,

Reviewing the patch sources I found few inconsistent decisions not
mentioned in RFC.

1. static typed properties are prohibited. why?

2. The handling of multiple properties in the same declaration statement
   is inconsistent.

    public int $bar, string $qux; // this works
   
    public int $bar, $qux; //this emits error: Untyped property
   

A::$qux must not be mixed with typed properties

It's better to allow type only before first property in the list and
apply them to all of them (like C, Java and others).
Is this just an implementation issue?

3. We already have nullable arguments without any special syntax. We
   should reuse the similar approach for properties.

public int $num = null;

4. There's a mess with initialization of typed properties. (typed
   properties are initialized by IS_UNDEF, untyped by IS_NULL).
   I think it might be better to implicitly initialize them according to
   type (if default value is not provided): bool by false, int by 0, double by
   0.0, string by "" (interned), array by [] (immutable), objects by NULL
   (always nullable).

Also I found a number of implementation problems:

5. We can't change property_info->type_ce for internal properties,
   because they are shared between threads.
   Can property of Internal class have a type of user class? This would lead
   to crash on second request.

6. $x->a++; doesn't throw on overflow

7. ++$a->a; and += throw on overflow, but change the property value to
   "float"

8. Reference handling in ZEND_FETCH_OBJ_W is not robust. At least,
   EXT_NOP or TICK may be inserted before next ASSIGN_REF. Handling of
   ZEND_ADD_ARRAY_ELEMENT and ZEND_YIELD is too pessimistic, missing support
   for SEND_REF and may be others.

9. Often calls to zend_object_fetch_property_type_info() are not good for
   performance. Currently FETCH_OBJ_X cache "offset" to property, in general
   we may go back and cache address of "property_info", but this is going to
   decrease performance for each property access. It would be great to find a
   better solution. May be using zval.reserved.

I assume, I didn't find all problems yet.

I think, both RFC and implementation have problems.
I may try to help with implementation.
(9) is the most difficult problem, and I'll try to solve it first.
Do you see any problems with updating RFC with (2), (3), (4)?
(1) would also make proposal more consistent, but I assume you got some
troubles implementing it and I don't know about them yet.

Thanks. Dmitry.

---

From: Dmitry Stogov dmitry@zend.com
Sent: Tuesday, March 29, 2016 19:24
To: Joe Watkins
Cc: Phil Sturgeon; krakjoe@php.net; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties

Thanks. I'll start tomorrow morning and will try to send you update by
the evening,

---

From: Joe Watkins pthreads@pthreads.org
Sent: Tuesday, March 29, 2016 19:18
To: Dmitry Stogov
Cc: Phil Sturgeon; krakjoe@php.net; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties

Hi Dmitry,

The patch is pretty close to complete.

When you start to dig a bit further, you'll notice that I prepared

for using cached pointers to prop info, but, I'm not sure how to allocate
those as the handlers are using the currently allocated slots so
differently.

I also patched opcache, but it's probably wrong (or not good enough,

not sure what to do about type_ce).

Please do start working on the patch, that would be great ... I'll

leave it alone for you to do your thing :)

Cheers
Joe

On Tue, Mar 29, 2016 at 5:12 PM, Dmitry Stogov <dmitry@zend.com<mailto:
dmitry@zend.com>> wrote:
Hi Phil, hi Joe,

Is your patch complete?

I took just a brief review yet, and I would like to make a deep check
once again (and may be optimization).
I saw, the patch makes some slowdown, but less than I expected.
If you are not going to modify the patch in next two days, I would start
working on it tomorrow.

RFC itself looks fine.

Thanks. Dmitry.

---

From: Phil Sturgeon <pjsturgeon@gmail.commailto:pjsturgeon@gmail.com>
Sent: Tuesday, March 29, 2016 18:32
To: Andrey Andreev
Cc: internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties

I'd like to thank everyone for their feedback on this RFC!

It looks like the majority of concerns were solved during the course
of this discussion, which is great news.

The RFC has been expanded in a few areas to take care of a few other
concerns, so please go and review it and let me know if you have any
feedback.

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

Voting will start in a few days.

Cheers,
Phil

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.

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.

From the user perspective there is not a lot of difference between
regular and static properties.

Instance properties, the engine has good control over their
manipulation, for static properties it doesn't, it's not impossible,
but feels separate.

so this is an implementation problem.

2. The handling of multiple properties in the same declaration
   statement is inconsistent.

This feels consistent to me .. in other languages where the type is
required, it makes sense to assume the type is implied.

In a language where the type is optional, public int $foo, $bar; feels
ambiguous to me.

But this is the valid syntax for others. And this is going to be yet
another reason to blame PHP.

3. We already have nullable arguments without any special syntax. We
   should reuse the similar approach for properties.

Making properties implicitly nullable defeats the object of trying to
provide type safety.

Null is never a valid value for a typed property, if it were, you
would never be sure of the type of variable you are getting, and would
have to litter your code with is_null checks.

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.

I think it might be better to implicitly initialize them according
to type (if default value is not provided): bool by false, int by 0,
double by 0.0, string by "" (interned), array by [] (immutable),
objects by NULL (always nullable).

Definitely not, lying about the default value isn't a good idea.

There are times when 0 is as valid as 1, or any other value for an int.

If you have declared that you know the type of the property, and you
write code that accesses that property before there is any possible
chance you have set the property, that's a programming error.

We should not hide that error with a default value, or by allowing the
engine to return null.

Your arguments may make sense, but PHP never required property
initialization. Introducing orthogonal rules for typed properties seems
strange.

We can't change property_info->type_ce for internal properties,
because they are shared between threads.

I'm not sure what to do about that ... will think ...
may be it's possible to make a special pass at the end of MINIT to
initialize all property_info->type_ce, for all internal classes.

6. and 7) and 8) just sound like bugs ... will look at those ...

7. I always intended to leave that to you :)

I'll spend some time trying to find a good solution.

Thanks. Dmitry.

Cheers
Joe

On Tue, Mar 29, 2016 at 11:59 PM, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Hi,

Reviewing the patch sources I found few inconsistent decisions not
mentioned in RFC.

1) static typed properties are prohibited. why?

2) The handling of multiple properties in the same declaration
statement is inconsistent.

        public int $bar, string $qux; // this works

        public int $bar, $qux; //this emits error: Untyped
property A::$qux must not be mixed with typed properties

It's better to allow type only before first property in the list
and apply them to all of them (like C, Java and others).
Is this just an implementation issue?

3) We already have nullable arguments without any special syntax.
We should reuse the similar approach for properties.

public int $num = null;

4) There's a mess with initialization of typed properties. (typed
properties are initialized by IS_UNDEF, untyped by IS_NULL).
I think it might be better to implicitly initialize them according
to type (if default value is not provided): bool by false, int by
0, double by 0.0, string by "" (interned), array by []
(immutable), objects by `NULL` (always nullable).

Also I found a number of implementation problems:

5) We can't change property_info->type_ce for internal properties,
because they are shared between threads.
Can property of Internal class have a type of user class? This
would lead to crash on second request.

6) $x->a++; doesn't throw on overflow

7) ++$a->a; and += throw on overflow, but change the property
value to "float"

8) Reference handling in ZEND_FETCH_OBJ_W is not robust. At least,
EXT_NOP or TICK may be inserted before next ASSIGN_REF. Handling
of ZEND_ADD_ARRAY_ELEMENT and ZEND_YIELD is too pessimistic,
missing support for SEND_REF and may be others.

9) Often calls to zend_object_fetch_property_type_info() are not
good for performance. Currently FETCH_OBJ_X cache "offset" to
property, in general we may go back and cache address of
"property_info", but this is going to decrease performance for
each property access. It would be great to find a better solution.
May be using zval.reserved.

I assume, I didn't find all problems yet.

I think, both RFC and implementation have problems.
I may try to help with implementation.
(9) is the most difficult problem, and I'll try to solve it first.
Do you see any problems with updating RFC with (2), (3), (4)?
(1) would also make proposal more consistent, but I assume you got
some troubles implementing it and I don't know about them yet.

Thanks. Dmitry.


________________________________________
From: Dmitry Stogov <dmitry@zend.com <mailto:dmitry@zend.com>>
Sent: Tuesday, March 29, 2016 19:24
To: Joe Watkins
Cc: Phil Sturgeon; krakjoe@php.net <mailto:krakjoe@php.net>;
internals@lists.php.net <mailto:internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties

Thanks. I'll start tomorrow morning and will try to send you
update by the evening,

________________________________
From: Joe Watkins <pthreads@pthreads.org
<mailto:pthreads@pthreads.org>>
Sent: Tuesday, March 29, 2016 19:18
To: Dmitry Stogov
Cc: Phil Sturgeon; krakjoe@php.net <mailto:krakjoe@php.net>;
internals@lists.php.net <mailto:internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties

Hi Dmitry,

    The patch is pretty close to complete.

    When you start to dig a bit further, you'll notice that I
prepared for using cached pointers to prop info, but, I'm not sure
how to allocate those as the handlers are using the currently
allocated slots so differently.

    I also patched opcache, but it's probably wrong (or not good
enough, not sure what to do about type_ce).

    Please do start working on the patch, that would be great ...
I'll leave it alone for you to do your thing :)

Cheers
Joe

On Tue, Mar 29, 2016 at 5:12 PM, Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com><mailto:dmitry@zend.com
<mailto:dmitry@zend.com>>> wrote:
Hi Phil, hi Joe,

Is your patch complete?

I took just a brief review yet, and I would like to make a deep
check once again (and may be optimization).
I saw, the patch makes some slowdown, but less than I expected.
If you are not going to modify the patch in next two days, I would
start working on it tomorrow.

RFC itself looks fine.

Thanks. Dmitry.

________________________________________
From: Phil Sturgeon <pjsturgeon@gmail.com
<mailto:pjsturgeon@gmail.com><mailto:pjsturgeon@gmail.com
<mailto:pjsturgeon@gmail.com>>>
Sent: Tuesday, March 29, 2016 18:32
To: Andrey Andreev
Cc: internals@lists.php.net
<mailto:internals@lists.php.net><mailto:internals@lists.php.net
<mailto:internals@lists.php.net>>
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties

I'd like to thank everyone for their feedback on this RFC!

It looks like the majority of concerns were solved during the course
of this discussion, which is great news.

The RFC has been expanded in a few areas to take care of a few other
concerns, so please go and review it and let me know if you have any
feedback.

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

Voting will start in a few days.

Cheers,
Phil

2. The handling of multiple properties in the same declaration statement
   is inconsistent.

This feels consistent to me .. in other languages where the type is
required, it makes sense to assume the type is implied.

In a language where the type is optional, public int $foo, $bar; feels
ambiguous to me.

We support

$ php -r 'class C { private static $a, $b; } echo new
ReflectionClass("C");'
[...]

• Static properties [2] {
  Property [ <default> private static $a ]
  Property [ <default> private static $b ]
  [...]

I believe handling the type attribute like access attributes would be
consistent.

But well, unless we have typed variables etc. this is inconsistent
anyways.
Maybe we should actually discuss making PHP fully typed and making that
consistent instead of adding one piece of typing step by step.

johannes

Den 2016-03-30 kl. 05:16, skrev Joe Watkins:

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.
Good that it's clarified in the RFC since one could easily
believe that it's possible to set type for a static property.

2. The handling of multiple properties in the same declaration statement
   is inconsistent.

This feels consistent to me .. in other languages where the type is
required, it makes sense to assume the type is implied.

In a language where the type is optional, public int $foo, $bar; feels
ambiguous to me.
Given that public is implied for all properties above there
is a value in having the same rule for type.

3. We already have nullable arguments without any special syntax. We
   should reuse the similar approach for properties.

Making properties implicitly nullable defeats the object of trying to
provide type safety.

Null is never a valid value for a typed property, if it were, you would
never be sure of the type of variable you are getting, and would have to
litter your code with is_null checks.
Maybe good to clarify difference towards default parameters?
Anyway, in Hack following syntax passes: https://3v4l.org/3tUu9

I think it might be better to implicitly initialize them according to
type (if default value is not provided): bool by false, int by 0, double by
0.0, string by "" (interned), array by [] (immutable), objects by NULL
(always nullable).

Definitely not, lying about the default value isn't a good idea.

There are times when 0 is as valid as 1, or any other value for an int.

If you have declared that you know the type of the property, and you write
code that accesses that property before there is any possible chance you
have set the property, that's a programming error.

We should not hide that error with a default value, or by allowing the
engine to return null.
Don't have a strong opinion on this one, can see both views.
Maybe a bit affected by programming in Java recently, having
a slightly more positive attitude towards default values ;-)

Regards //Björn Larsson