[RFC] Typed Properties

Marco Pivetta

8 years ago

Hi Nikita, Bob,

On Wed, 20 Jun 2018, 23:59 Nikita Popov, <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>     https://wiki.php.net/rfc/typed_properties_v2
>
> The proposal allows you to annotate properties with types, which are
> enforced at runtime. Unlike the previous RFC on this topic, the new
> proposal also supports typed static properties and references to typed
> properties.
>
> Please note that next to the main body, the RFC also contains an
> "Alternatives" section, which explores the problem space and considers
> trade-offs of different behaviors in some detail.
>
> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>
> Regards,
> Nikita
>

This is awesome news! I skimmed over the proposal and it is extremely well
thought out, and almost everything that was causing a -1 on the previous
RFC is gone: kudos!

The last bit that is missing is the `__get` kink, mostly because `__get()`
is "squishy by design". Still, the fact that references are properly typed
mitigates the issue for my shady use-cases (I've got a reputation there),
so I'm quite happy with an implicit magic type check. One thing I couldn't
find is whether this magic check is also enforced when calling `__get()`
explicitly, and not via the guards in the engine.

Is the current development branch usable for testing something locally? I
can't see any obvious mistakes here, but I just wanted to try this out with
some of the more obscure libraries that touch property state at the level
that is covered by this RFC.

Bob Weinand

8 years ago

> From: Marco Pivetta <ocramius@gmail.com>
> Sent: Thursday, June 21, 2018 01:10
> To: Nikita Popov <nikita.ppv@gmail.com>
> Cc: PHP Internals List <internals@lists.php.net>
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
>
> Hi Nikita, Bob,
>
> On Wed, 20 Jun 2018, 23:59 Nikita Popov, <nikita.ppv@gmail.com> wrote:
>
> > Hi internals,
> >
> > Bob and I would like to present a new typed properties proposal for
> > your
> > consideration:
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
> >
> .php.net%2Frfc%2Ftyped_properties_v2&data=02%7C01%7C%7Ca414560298
> 8f413
> >
> 3a54808d5d7031564%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6
> 366513
> >
> 30591392793&sdata=M70Asi8WqXbP6icXeVsdsBuI1GiK9UjgHj9EoZHX4%2Bg
> %3D&res
> > erved=0
> >
> > The proposal allows you to annotate properties with types, which are
> > enforced at runtime. Unlike the previous RFC on this topic, the new
> > proposal also supports typed static properties and references to typed
> > properties.
> >
> > Please note that next to the main body, the RFC also contains an
> > "Alternatives" section, which explores the problem space and considers
> > trade-offs of different behaviors in some detail.
> >
> > Finally, while this RFC currently targets PHP 7.3, this is a large and
> > complex proposal and we may not be able to meet the deadline, in which
> > case this feature will go into the next PHP version.
> >
> > Regards,
> > Nikita
> >
>
> This is awesome news! I skimmed over the proposal and it is extremely well
> thought out, and almost everything that was causing a -1 on the previous RFC
> is gone: kudos!
>
> The last bit that is missing is the `__get` kink, mostly because `__get()` is
> "squishy by design". Still, the fact that references are properly typed
> mitigates the issue for my shady use-cases (I've got a reputation there), so
> I'm quite happy with an implicit magic type check. One thing I couldn't find is
> whether this magic check is also enforced when calling `__get()` explicitly,
> and not via the guards in the engine.
>
> Is the current development branch usable for testing something locally? I
> can't see any obvious mistakes here, but I just wanted to try this out with
> some of the more obscure libraries that touch property state at the level that
> is covered by this RFC.

__get() is a very normal function - the special semantics are generally only applied if called for overloaded properties. So obviously, there is no check applied if you call it directly.

The dev branch is stable for testing, yes. Would appreciate reports about any bugs you find.

Bob

Marco Pivetta

8 years ago

Hi Bob,

On Thu, Jun 21, 2018 at 1:42 AM, Bob Weinand <bobwei9@hotmail.com> wrote:

> __get() is a very normal function - the special semantics are generally
> only applied if called for overloaded properties. So obviously, there is no
> check applied if you call it directly.
>

Thanks!

The dev branch is stable for testing, yes. Would appreciate reports about

> any bugs you find.
>

That shall be my weekend task. I'll stress this stuff in the ProxyManager
test suite: if it passes there, it really is rock-solid.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Gabriel Caruso

8 years ago

Nikita, Bob

I'd love to thank you and everyone involved on this one. Types properties
on PHP is something that we tried before, but due to a number of issues, we
didn't make it. Unfortunately, I don't have the knowledge to help in the
implementation, but I'd like to drop some comments about the syntax.

As described in https://wiki.php.net/rfc/typed_properties_v2#syntax, I
think we should only allow
class Example {
public int $num;
public string $name;
}

Allow the `:` variant (`public $num: int;`) would bring a lot of doubts for
new users, and the `{visibility} {type} {name}` is prett consistence in
other languages.

Again, thanks for this amazing work, and let's make for the next PHP
version :)

--
Gabriel Caruso

Sara Golemon

8 years ago

On Wed, Jun 20, 2018 at 4:59 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>     https://wiki.php.net/rfc/typed_properties_v2
>

At a glance, yes please.  Will dig in deeper when I'm not busy moving.

> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>

IMO it's already too late for something of this size to realistically
make 7.3. If a vote comes up targeting 7.3 I intend to vote no purely
on procedural grounds. A 7.4 target will quite probably see a yes from
me, however.

-Sara

Bob Weinand

8 years ago

Hey Sara,

> From: php@golemon.com <php@golemon.com> On Behalf Of Sara Golemon
> Sent: Thursday, June 21, 2018 15:43
> To: Nikita Popov <nikita.ppv@gmail.com>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
>
> On Wed, Jun 20, 2018 at 4:59 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > Finally, while this RFC currently targets PHP 7.3, this is a large and
> > complex proposal and we may not be able to meet the deadline, in which
> > case this feature will go into the next PHP version.
> >
> IMO it's already too late for something of this size to realistically make 7.3. If a
> vote comes up targeting 7.3 I intend to vote no purely on procedural
> grounds. A 7.4 target will quite probably see a yes from me, however.
>
> -Sara

I agree that we're pretty late to the party, however I see typed properties being a pretty central feature to the PHP 7.3 feature set then, just because of its size.
I think it may be worth pushing the release of 7.3  a few weeks back instead, if we decide to have this feature make it into PHP 7.3.

The current feature set of PHP 7.3 is pretty small, and I consider it a good idea to see how typed properties play out in 7.3 before we consider other typesystem improvements.
Waiting a year more would give us less insight into what people are still missing and wishing for.

Thus I don't consider it a very good idea to be too conservative here.

An other option would be though, to include a secondary vote "7.3, 7.3 and a little delay or 7.4".

Bob

Sara Golemon

8 years ago

On Thu, Jun 21, 2018 at 9:13 AM, Bob Weinand <bobwei9@hotmail.com> wrote:

> I agree that we're pretty late to the party, however I see typed properties being
> a pretty central feature to the PHP 7.3 feature set then, just because of its size.
> I think it may be worth pushing the release of 7.3  a few weeks back instead,
> if we decide to have this feature make it into PHP 7.3.
>

To quote Nikita: https://twitter.com/nikita_ppv/status/1009800042629271553
"Just to make sure we're on the same page: What I mean is that an
initial implementation *has* to land before branching, but has a lot
of time to bake afterwards. If the implementation is not good enough
to land before branching, then it can't go into 7.3."

I'm fine with that take on it.  If we can get to consensus quickly
enough to get a vote closed by the end of July (which, incidentally,
allows for a bit past the feature freeze date), then I can get behind
it without a additional delay.  If we CAN'T close the vote by then,
and we're not willing to push the dates out to accommodate, them
that's where my 'no' comes from.

Last year at this time, a certain new extension rolled right up to the
wire and bit beyond and it was a mess.  Half the post-branch fixes and
API changes didn't even hit the 7.2 branch (without messy
cherry-picks) because the committer wasn't paying attention or
responding to attempts at communication.  Yes, you and Niki are much
better plugged in, but other stuff comes up when you leave things for
the last minute, and I don't want to see 7.3 have issues as well.

-Sara

Christoph Becker

8 years ago

On 21.06.2018 at 16:50, Sara Golemon wrote:

> On Thu, Jun 21, 2018 at 9:13 AM, Bob Weinand <bobwei9@hotmail.com> wrote:
>
>> I agree that we're pretty late to the party, however I see typed properties being
>> a pretty central feature to the PHP 7.3 feature set then, just because of its size.
>> I think it may be worth pushing the release of 7.3  a few weeks back instead,
>> if we decide to have this feature make it into PHP 7.3.
>
> To quote Nikita: https://twitter.com/nikita_ppv/status/1009800042629271553
> "Just to make sure we're on the same page: What I mean is that an
> initial implementation *has* to land before branching, but has a lot
> of time to bake afterwards. If the implementation is not good enough
> to land before branching, then it can't go into 7.3."
>
> I'm fine with that take on it.  If we can get to consensus quickly
> enough to get a vote closed by the end of July (which, incidentally,
> allows for a bit past the feature freeze date), then I can get behind
> it without a additional delay.  If we CAN'T close the vote by then,
> and we're not willing to push the dates out to accommodate, them
> that's where my 'no' comes from.

Note that branching of PHP-7.3 is presently scheduled for July, 17th,
though, see <https://wiki.php.net/todo/php73>.

--
Christoph M. Becker

Nicolas Grekas

8 years ago

Hi Nikita, Bob,

https://wiki.php.net/rfc/typed_properties_v2

>

This is really well thought and written, sounds really primising.
I agree that "References without intrinsic type" look the best.

I anticipate one case on Symfony VarDumper that will break on typed
references:

the only way to detect references is by injecting cookies in arrays, e.g.:
$a = (array) $someObjectOrArray;
$cookie = new stdClass();
$b = $a;
$b[$k] = $cookie;
if ($a[$k] === $cookie) {
// Here we have a reference
}

I'd need to wrap the assignation in a try/catch now:
try {
$b[$k] = $cookie;
} catch (TypeError $e) {
// Here we have a typed reference that doesn't accept stdclass
}

So far so good I suppose. I just wanted to raise the point if it matters at
all.

Thank you,
Nicolas

Bob Weinand

8 years ago

> From: nicolas.grekas@gmail.com <nicolas.grekas@gmail.com> On Behalf Of
> Nicolas Grekas
> Sent: Thursday, June 21, 2018 16:08
> To: Nikita Popov <nikita.ppv@gmail.com>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
>
> Hi Nikita, Bob,
>
> I anticipate one case on Symfony VarDumper that will break on typed
> references:
>
> the only way to detect references is by injecting cookies in arrays, e.g.:
> $a = (array) $someObjectOrArray;
> $cookie = new stdClass();
> $b = $a;
> $b[$k] = $cookie;
> if ($a[$k] === $cookie) {
>   // Here we have a reference
> }
>
> I'd need to wrap the assignation in a try/catch now:
> try {
>     $b[$k] = $cookie;
> } catch (TypeError $e) {
>   // Here we have a typed reference that doesn't accept stdclass }
>
> So far so good I suppose. I just wanted to raise the point if it matters at all.
>
> Thank you,
> Nicolas

We haven't implemented that (yet?), but I considered something like a ReflectionReference class, which will give you the referencing properties via ReflectionProperty instances.
The implementation easily allows for that as it tracks the referencing properties for calculating the allowed types.

I didn't consider it essential for the initial implementation in 7.3 and thus hadn't written it on the TODO list for that RFC.
But if you think it's important (it has real world needs), then we may consider extending the RFC to include that.

Bob

Nicolas Grekas

8 years ago

> something like a ReflectionReference class, which will give you the
> referencing properties via ReflectionProperty instances
>

I may not have the object when walking on data structures, but only the
reference (in an array.)
It could work this way I suppose: `ReflectionReference::fromArray(array
$array, string $key): ?ReflectionReference`,
returning `null` when `$array[$key]` is not a reference, and the instance
otherwise.
WDYT?

Bob Weinand

8 years ago

From: nicolas.grekas@gmail.com <nicolas.grekas@gmail.com> On Behalf Of Nicolas Grekas
Sent: Thursday, June 21, 2018 18:51
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>; PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Typed Properties

something like a ReflectionReference class, which will give you the referencing properties via ReflectionProperty instances

I may not have the object when walking on data structures, but only the reference (in an array.)
It could work this way I suppose: `ReflectionReference::fromArray(array $array, string $key): ?ReflectionReference`,
returning `null` when `$array[$key]` is not a reference, and the instance otherwise.
WDYT?

I imagined a ReflectionReference::__construct(&$value), with methods getRefcount() : int and getReferencingProperties() : ReflectionProperty[]

To check whether it’s a reference at all, you’d use if ((new ReflectionReference($array[$key]))->getRefcount() > 2) { /* is ref */ } else { /* not a ref */ }, for computing the allowed types you’d intersect the types of the ReflectionProperties returned by getReferencingProperties().

Bob

Nicolas Grekas

8 years ago

>
> if ((new ReflectionReference($array[$key]))->getRefcount() > 2) { /* is
> ref */ } else { /* not a ref */ }, for computing the allowed types you’d
> intersect the types of the ReflectionProperties returned by
> getReferencingProperties().
>

Would work also I suppose, sounds good thanks for caring :)

Nicolas Grekas

8 years ago

Le jeu. 21 juin 2018 à 19:37, Nicolas Grekas <nicolas.grekas+php@gmail.com>
a écrit :

> if ((new ReflectionReference($array[$key]))->getRefcount() > 2) { /* is
>> ref */ } else { /* not a ref */ }, for computing the allowed types you’d
>> intersect the types of the ReflectionProperties returned by
>> getReferencingProperties().
>>
>

I just realized that this interface would suffer from a significant
drawback: it would trigger COW when iterating over immutable arrays,
defeating the shared-memory optimization provided by OPcache.

An interface like new ReflectionReference($array, $key) would be free from
the issue. Combined with get_defined_vars() and the (array) operator for
objects, we can inspect any PHP data structure or scope also this way.

Nicolas

Rowan Collins

8 years ago

On 06/07/2018 21:57, Nicolas Grekas wrote:

>
>> if ((new ReflectionReference($array[$key]))->getRefcount() > 2) {
> I just realized that this interface would suffer from a significant
> drawback: it would trigger COW when iterating over immutable arrays,
> defeating the shared-memory optimization provided by OPcache.

Any implementation of this that acts like a normal function /
constructor call is going to suffer from the same problems as
debug_zval_dump: passing a variable from one scope to another will
change the properties of that variable. If you accept the variable by
reference, you'll duplicate the data if it's part of a COW set (which
has nothing to do with OpCache by the way, it's been a core part of the
engine since at least 5.0); if you accept it by value, you'll duplicate
the data if it's part of a reference set. Either way, you're going to
change the refcount on the zval, hence the awkward 2 in Bob's example.

Previous discussions of that function concluded that the only "correct"
way to implement this would be as a language feature rather than a true
function - if the compiler issues a specific OpCode, it can pull the
zval straight out of the symbol table, without interfering with it.

Maybe the two concepts could be combined, and the language feature
generate a Reflection object? e.g.

$reflection = reflect_variable($var);
if ( $reflection->isReference() ) {
    $types = $reflection->getReferencedTypes();
}

> An interface like new ReflectionReference($array, $key) would be free from
> the issue. Combined with get_defined_vars() and the (array) operator for
> objects, we can inspect any PHP data structure or scope also this way.

Yuck. Even if this solves the issue of supporting both ref and non-ref
variables, you still end up having to compensate for the wrong refcount,
and the resultant code would be ugly as sin.

Regards,

--
Rowan Collins
[IMSoP]

Stephen Reay

8 years ago

> On 21 Jun 2018, at 4:59 am, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>    https://wiki.php.net/rfc/typed_properties_v2
>
> The proposal allows you to annotate properties with types, which are
> enforced at runtime. Unlike the previous RFC on this topic, the new
> proposal also supports typed static properties and references to typed
> properties.
>
> Please note that next to the main body, the RFC also contains an
> "Alternatives" section, which explores the problem space and considers
> trade-offs of different behaviors in some detail.
>
> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>
> Regards,
> Nikita

Hi Nikita/Bob,

I’m *really* happy to see someone taking another stab at this.

My only ‘input’ as such, is around the decision to omit `callable`. Given that we *have* Closures (thus allowing a developer to explicitly state that they want something they can invoke regardless of context, if they so wish), I think `callable` should be a valid type for properties too. The language doesn’t prevent floating point math because you might not get the result you expect - it simply documents and warns people that they need to be aware of some inherent attributes of the feature.

Whether that particular aspect of the RFC changes or not, again, thank you both for working on this!

Cheers

Stephen

Larry Garfield

8 years ago

On Wednesday, June 20, 2018 4:59:33 PM CDT Nikita Popov wrote:

> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>     https://wiki.php.net/rfc/typed_properties_v2
>
> The proposal allows you to annotate properties with types, which are
> enforced at runtime. Unlike the previous RFC on this topic, the new
> proposal also supports typed static properties and references to typed
> properties.
>
> Please note that next to the main body, the RFC also contains an
> "Alternatives" section, which explores the problem space and considers
> trade-offs of different behaviors in some detail.
>
> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>
> Regards,
> Nikita

I am in full squee-mode over this.  I'd love to see it, in whichever version
is deemed appropriate.  (7.3 would be nice, 7.4 would still be acceptable.)

Questions along the way:

* There was at one point in time a related RFC regarding property accessors
(dedicated getter/setter methods for each property that get called
automatically).  That was rejected largely on performance grounds at the time.
Would this RFC 1) Hinder returning to property accessors in the future 2) Help
resolve some of the issues there indirectly 3) Have no effect on the viability
of accessors?

* How much compile time detection is possible?  Eg, the following code would
clearly never work:

class Foo {
protected int $val;

public function setVal(string $val) : void {
$this->val = $val;
}

public function getVal() : string {
return $this->val;
}
}

(I suppose technically it might work in coercive mode, but not strict mode?)
Would this be a compile time error, or a runtime error when you first try to
run it?  (I'm assuming IDE linters would be able to catch it, but if the
engine could too that's even better.)

Bob Weinand

8 years ago

Hey Larry,

> From: Larry Garfield <larry@garfieldtech.com>
> Sent: Thursday, June 21, 2018 18:17
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> Questions along the way:
>
> * There was at one point in time a related RFC regarding property

accessors

> (dedicated getter/setter methods for each property that get called
> automatically).  That was rejected largely on performance grounds at the
> time.
> Would this RFC 1) Hinder returning to property accessors in the future 2)

Help

> resolve some of the issues there indirectly 3) Have no effect on the

viability

> of accessors?

I don't think it'll hinder them, accessors are pretty orthogonal to this
feature. Sure they'll have to cast the returned value according to the
property type, but that's no different than a return type and just like
__get() works in this RFC. But that's already about the complete impact.
An accessor ultimately isn't really any more expensive than a __get() call
at a fundamental level.

> * How much compile time detection is possible?  Eg, the following code
> would clearly never work:
>
> class Foo {
>   protected int $val;
>
>   public function setVal(string $val) : void {
>     $this->val = $val;
>   }
>
>   public function getVal() : string {
>     return $this->val;
>   }
> }
>
> (I suppose technically it might work in coercive mode, but not strict

mode?)

> Would this be a compile time error, or a runtime error when you first try

to

> run it?  (I'm assuming IDE linters would be able to catch it, but if the

engine

> could too that's even better.)

PHP core generally does no type analysis at all at compile-time. Any type
analysis is happening in opcache/Optimizer and until now opache/Optimizer
hasn't chosen to warn if it encounters impossible conditions. This may or
may not change in future, but isn't related here.
So it is a runtime error; any other behavior would be out of scope of this
RFC.

Bob

Patrick ALLAERT

8 years ago

Le jeu. 21 juin 2018 à 00:00, Nikita Popov <nikita.ppv@gmail.com> a écrit :

> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>     https://wiki.php.net/rfc/typed_prwould some benefitsoperties_v2
> <https://wiki.php.net/rfc/typed_properties_v2>
>
> The proposal allows you to annotate properties with types, which are
> enforced at runtime. Unlike the previous RFC on this topic, the new
> proposal also supports typed static properties and references to typed
> properties.
>
> Please note that next to the main body, the RFC also contains an
> "Alternatives" section, which explores the problem space and considers
> trade-offs of different behaviors in some detail.
>
> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>
> Regards,
> Nikita
>

Hi Nikita, Bob,

Congrats for the awesome job! It looks very good.

My only concern is about regular variables, not bound to any classes. Isn't
that a little bit inconsistent that classes properties could be typed, but
not a regular variable in the middle of a function/method/plain "script"
file?

I would see some benefit doing something like:

string $content = file_get_contents("/foo/bar");

(Sorry if this has been raised already in the past)

Patrick

Bob Weinand

8 years ago

> From: Patrick ALLAERT <patrickallaert@php.net>
> Sent: Thursday, June 21, 2018 18:25
> To: Nikita Popov <nikita.ppv@gmail.com>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
>
> My only concern is about regular variables, not bound to any classes. Isn't
> that a little bit inconsistent that classes properties could be typed, but not a
> regular variable in the middle of a function/method/plain "script"
> file?
>
> I would see some benefit doing something like:
>
> string $content = file_get_contents("/foo/bar");
>
> (Sorry if this has been raised already in the past)
>
> Patrick

Hey Patrick,

It is an option to allow this in future, but for now I consider this too far out of scope, possiv and it will, in particular also require greater changes to the engine - I guess it would about double the size of the patch again. (and this patch is already everything, but small.)

This feature would as well be possibly not uncontroversial, needs thinking about the scoping of the variable type (Lifetime until unset()? Lifetime until function end? etc.) - I definitely would not go too far with this RFC. The topic is typed properties and that's what the scope of the RFC shall also be.

Bob

Stas Malyshev

8 years ago

Hi!

> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.

I haven't read the RFC yet, so I just want to address this point. I
think unless the RFC is exceptionally perfect and produces universal
acceptance instantly (may be exactly the case, as I said, I haven't read
it :), we should default to targeting 7.4. 7.3 release cycle has already
began, and we're pretty close to feature freeze. I think it's better not
to feel pressured by the deadline for 7.3 - especially given that summer
is a vacation season and some people may be slow to give feedback due to
that - and let it work through. Rushing with it may cause us (even
unconsciously) to cut corners, not have discussions that should be had,
not test it as thoroughly, etc. Especially on a thing of this magnitude.

Note I am not opposed to having it in 7.3 if it all works out better and
faster than my cautiously pessimistic assumptions - I just think we
should not presume it'd necessarily be the case and feel the pressure to
do it at the cost of more thorough work on it.

--
Stas Malyshev
smalyshev@gmail.com

Dan Ackroyd

8 years ago

On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com> wrote:

>
> I think it's better not
> to feel pressured by the deadline for 7.3

The deadline isn't a deadline - it's just the current consensus for
when we'd like to see 7.3 released.

If people thought this RFC needed more time but would make PHP 7.3 a
lot better, would there be any harm in moving the 7.3 release back a
few weeks?

cheers
Dan

Sara Golemon

8 years ago

On Thu, Jun 21, 2018 at 12:57 PM, Dan Ackroyd <danack@basereality.com> wrote:

> On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>>
>> I think it's better not
>> to feel pressured by the deadline for 7.3
>
> The deadline isn't a deadline - it's just the current consensus for
> when we'd like to see 7.3 released.
>
> If people thought this RFC needed more time but would make PHP 7.3 a
> lot better, would there be any harm in moving the 7.3 release back a
> few weeks?
>

Sure.  I would *far* prefer that over jamming this in without any
change in the GA date.  We have to be careful about exactly when we
push it to.  The current GA date wasn't chosen arbitrarily, but with
concern regarding the proximity to the holiday season.

-Sara

Björn Larsson

8 years ago

Den 2018-06-21 kl. 20:41, skrev Sara Golemon:

> On Thu, Jun 21, 2018 at 12:57 PM, Dan Ackroyd <danack@basereality.com> wrote:
>> On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>>> I think it's better not
>>> to feel pressured by the deadline for 7.3
>> The deadline isn't a deadline - it's just the current consensus for
>> when we'd like to see 7.3 released.
>>
>> If people thought this RFC needed more time but would make PHP 7.3 a
>> lot better, would there be any harm in moving the 7.3 release back a
>> few weeks?
>>
> Sure.  I would *far* prefer that over jamming this in without any
> change in the GA date.  We have to be careful about exactly when we
> push it to.  The current GA date wasn't chosen arbitrarily, but with
> concern regarding the proximity to the holiday season.
>
> -Sara
>

Hi,

Any chance getting this into 7.3? I think it would be a
great addition. According to Marco Pivettas mail from
26/6 it works flawlessly.

Givven the current discussion about 8.0 it feels a bit
way off having this to wait for this feature until 2020.

r//Björn Larsson

Marco Pivetta

8 years ago

On Thu, Jul 5, 2018 at 11:09 AM, Björn Larsson <bjorn.x.larsson@telia.com>
wrote:

> it feels a bit
> way off having this to wait for this feature until 2020.
>

I didn't realise this. Now that I did:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!

Nikita Popov

8 years ago

On Thu, Jul 5, 2018 at 11:09 AM, Björn Larsson <bjorn.x.larsson@telia.com>
wrote:

> Den 2018-06-21 kl. 20:41, skrev Sara Golemon:
>
> On Thu, Jun 21, 2018 at 12:57 PM, Dan Ackroyd <danack@basereality.com>
>> wrote:
>>
>>> On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com>
>>> wrote:
>>>
>>>> I think it's better not
>>>> to feel pressured by the deadline for 7.3
>>>>
>>> The deadline isn't a deadline - it's just the current consensus for
>>> when we'd like to see 7.3 released.
>>>
>>> If people thought this RFC needed more time but would make PHP 7.3 a
>>> lot better, would there be any harm in moving the 7.3 release back a
>>> few weeks?
>>>
>>> Sure.  I would *far* prefer that over jamming this in without any
>> change in the GA date.  We have to be careful about exactly when we
>> push it to.  The current GA date wasn't chosen arbitrarily, but with
>> concern regarding the proximity to the holiday season.
>>
>> -Sara
>>
>> Hi,
>
> Any chance getting this into 7.3? I think it would be a
> great addition. According to Marco Pivettas mail from
> 26/6 it works flawlessly.
>
> Givven the current discussion about 8.0 it feels a bit
> way off having this to wait for this feature until 2020.
>

We have recently finished the last major change to the implementation
(switching to https://wiki.php.net/rfc/typed_properties_v2#
references_without_intrinsic_type -- the RFC still needs to be updated for
this change). However, there is still quite a bit of refactoring and polish
to be done. Unfortunately, we are running out of time. There are already
less than two weeks until the currently planned feature freeze, before
which the vote must be finished and the implementation merged. For such a
major feature, I don't like the idea of rushing the vote to such a degree.

As such, I think that this feature can only go into 7.3 if the release
schedule is adjusted. Extending the schedule by another 2-week alpha cycle
would be sufficient to land this proposal in PHP 7.3. Otherwise it will
just have to wait a few years for the next applicable release (based on
recent discussions, it's not entirely clear whether that would be PHP 7.4
or 8.0).

Regards,
Nikita

Sebastian Bergmann

8 years ago

> As such, I think that this feature can only go into 7.3 if the release
> schedule is adjusted. Extending the schedule by another 2-week alpha cycle
> would be sufficient to land this proposal in PHP 7.3.

+1

Björn Larsson

8 years ago

Den 2018-07-05 kl. 12:17, skrev Nikita Popov:

> On Thu, Jul 5, 2018 at 11:09 AM, Björn Larsson <bjorn.x.larsson@telia.com>
> wrote:
>
>> Den 2018-06-21 kl. 20:41, skrev Sara Golemon:
>>
>> On Thu, Jun 21, 2018 at 12:57 PM, Dan Ackroyd <danack@basereality.com>
>>> wrote:
>>>
>>>> On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com>
>>>> wrote:
>>>>
>>>>> I think it's better not
>>>>> to feel pressured by the deadline for 7.3
>>>>>
>>>> The deadline isn't a deadline - it's just the current consensus for
>>>> when we'd like to see 7.3 released.
>>>>
>>>> If people thought this RFC needed more time but would make PHP 7.3 a
>>>> lot better, would there be any harm in moving the 7.3 release back a
>>>> few weeks?
>>>>
>>>> Sure.  I would *far* prefer that over jamming this in without any
>>> change in the GA date.  We have to be careful about exactly when we
>>> push it to.  The current GA date wasn't chosen arbitrarily, but with
>>> concern regarding the proximity to the holiday season.
>>>
>>> -Sara
>>>
>>> Hi,
>> Any chance getting this into 7.3? I think it would be a
>> great addition. According to Marco Pivettas mail from
>> 26/6 it works flawlessly.
>>
>> Givven the current discussion about 8.0 it feels a bit
>> way off having this to wait for this feature until 2020.
>>
> We have recently finished the last major change to the implementation
> (switching to https://wiki.php.net/rfc/typed_properties_v2#
> references_without_intrinsic_type -- the RFC still needs to be updated for
> this change). However, there is still quite a bit of refactoring and polish
> to be done. Unfortunately, we are running out of time. There are already
> less than two weeks until the currently planned feature freeze, before
> which the vote must be finished and the implementation merged. For such a
> major feature, I don't like the idea of rushing the vote to such a degree.
>
> As such, I think that this feature can only go into 7.3 if the release
> schedule is adjusted. Extending the schedule by another 2-week alpha cycle
> would be sufficient to land this proposal in PHP 7.3. Otherwise it will
> just have to wait a few years for the next applicable release (based on
> recent discussions, it's not entirely clear whether that would be PHP 7.4
> or 8.0).
>
> Regards,
> Nikita
>

Sounds like the RMs for 7.3 need to weigh in on this.
For me I think it's worthwhile delaying two weeks, +1.

I also think that now we have an implementation that
works. For 8.0 the changes are not known, so delaying
could imply that implementation needs to be reworked,
i.e. a bit of double work.

r//Björn Larsson

Christoph Becker

8 years ago

On 05.07.2018 at 13:05, Björn Larsson wrote:

> Den 2018-07-05 kl. 12:17, skrev Nikita Popov:
>
>> On Thu, Jul 5, 2018 at 11:09 AM, Björn Larsson
>> <bjorn.x.larsson@telia.com>
>> wrote:
>>
>>> Den 2018-06-21 kl. 20:41, skrev Sara Golemon:
>>>
>>> On Thu, Jun 21, 2018 at 12:57 PM, Dan Ackroyd <danack@basereality.com>
>>>> wrote:
>>>>
>>>>> On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I think it's better not
>>>>>> to feel pressured by the deadline for 7.3
>>>>>>
>>>>> The deadline isn't a deadline - it's just the current consensus for
>>>>> when we'd like to see 7.3 released.
>>>>>
>>>>> If people thought this RFC needed more time but would make PHP 7.3 a
>>>>> lot better, would there be any harm in moving the 7.3 release back a
>>>>> few weeks?
>>>>>
>>>>> Sure.  I would *far* prefer that over jamming this in without any
>>>> change in the GA date.  We have to be careful about exactly when we
>>>> push it to.  The current GA date wasn't chosen arbitrarily, but with
>>>> concern regarding the proximity to the holiday season.
>>>
>>> Any chance getting this into 7.3? I think it would be a
>>> great addition. According to Marco Pivettas mail from
>>> 26/6 it works flawlessly.
>>>
>>> Givven the current discussion about 8.0 it feels a bit
>>> way off having this to wait for this feature until 2020.
>>
>> We have recently finished the last major change to the implementation
>> (switching to https://wiki.php.net/rfc/typed_properties_v2#
>> references_without_intrinsic_type -- the RFC still needs to be updated
>> for
>> this change). However, there is still quite a bit of refactoring and
>> polish
>> to be done. Unfortunately, we are running out of time. There are already
>> less than two weeks until the currently planned feature freeze, before
>> which the vote must be finished and the implementation merged. For such a
>> major feature, I don't like the idea of rushing the vote to such a
>> degree.
>>
>> As such, I think that this feature can only go into 7.3 if the release
>> schedule is adjusted. Extending the schedule by another 2-week alpha
>> cycle
>> would be sufficient to land this proposal in PHP 7.3. Otherwise it will
>> just have to wait a few years for the next applicable release (based on
>> recent discussions, it's not entirely clear whether that would be PHP 7.4
>> or 8.0).
>
> Sounds like the RMs for 7.3 need to weigh in on this.
> For me I think it's worthwhile delaying two weeks, +1.

Is there any precendent for postponing feature freeze during the (late)
alpha stage?

--
Christoph M. Becker

shinji igarashi

8 years ago

https://marc.info/?l=php-internals&m=136093001212358&w=2
Maybe the opcache case in PHP5.5 is a precendent, I think.

2018年7月5日(木) 20:26 Christoph M. Becker <cmbecker69@gmx.de>:

Nikita Popov

8 years ago

On Thu, Jul 5, 2018 at 1:25 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 05.07.2018 at 13:05, Björn Larsson wrote:
>
> > Den 2018-07-05 kl. 12:17, skrev Nikita Popov:
> >
> >> On Thu, Jul 5, 2018 at 11:09 AM, Björn Larsson
> >> <bjorn.x.larsson@telia.com>
> >> wrote:
> >>
> >>> Den 2018-06-21 kl. 20:41, skrev Sara Golemon:
> >>>
> >>> On Thu, Jun 21, 2018 at 12:57 PM, Dan Ackroyd <danack@basereality.com>
> >>>> wrote:
> >>>>
> >>>>> On 21 June 2018 at 17:49, Stanislav Malyshev <smalyshev@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I think it's better not
> >>>>>> to feel pressured by the deadline for 7.3
> >>>>>>
> >>>>> The deadline isn't a deadline - it's just the current consensus for
> >>>>> when we'd like to see 7.3 released.
> >>>>>
> >>>>> If people thought this RFC needed more time but would make PHP 7.3 a
> >>>>> lot better, would there be any harm in moving the 7.3 release back a
> >>>>> few weeks?
> >>>>>
> >>>>> Sure.  I would *far* prefer that over jamming this in without any
> >>>> change in the GA date.  We have to be careful about exactly when we
> >>>> push it to.  The current GA date wasn't chosen arbitrarily, but with
> >>>> concern regarding the proximity to the holiday season.
> >>>
> >>> Any chance getting this into 7.3? I think it would be a
> >>> great addition. According to Marco Pivettas mail from
> >>> 26/6 it works flawlessly.
> >>>
> >>> Givven the current discussion about 8.0 it feels a bit
> >>> way off having this to wait for this feature until 2020.
> >>
> >> We have recently finished the last major change to the implementation
> >> (switching to https://wiki.php.net/rfc/typed_properties_v2#
> >> references_without_intrinsic_type -- the RFC still needs to be updated
> >> for
> >> this change). However, there is still quite a bit of refactoring and
> >> polish
> >> to be done. Unfortunately, we are running out of time. There are already
> >> less than two weeks until the currently planned feature freeze, before
> >> which the vote must be finished and the implementation merged. For such
> a
> >> major feature, I don't like the idea of rushing the vote to such a
> >> degree.
> >>
> >> As such, I think that this feature can only go into 7.3 if the release
> >> schedule is adjusted. Extending the schedule by another 2-week alpha
> >> cycle
> >> would be sufficient to land this proposal in PHP 7.3. Otherwise it will
> >> just have to wait a few years for the next applicable release (based on
> >> recent discussions, it's not entirely clear whether that would be PHP
> 7.4
> >> or 8.0).
> >
> > Sounds like the RMs for 7.3 need to weigh in on this.
> > For me I think it's worthwhile delaying two weeks, +1.
>
> Is there any precendent for postponing feature freeze during the (late)
> alpha stage?
>

This was done for the PHP 7.1 release at pretty much the same time (before
the beta1 release it was decided to go with another alpha instead), for
much the same reasons (pending RFCs, though I don't remember the
specifics). See https://externals.io/message/94330 for the announcement
mail.

Nikita

Christoph Becker

8 years ago

On 05.07.2018 at 17:25, Nikita Popov wrote:

> On Thu, Jul 5, 2018 at 1:25 PM, Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
>> On 05.07.2018 at 13:05, Björn Larsson wrote:
>>
>>> Den 2018-07-05 kl. 12:17, skrev Nikita Popov:
>>>
>>>> As such, I think that this feature can only go into 7.3 if the release
>>>> schedule is adjusted. Extending the schedule by another 2-week alpha
>>>> cycle
>>>> would be sufficient to land this proposal in PHP 7.3. Otherwise it will
>>>> just have to wait a few years for the next applicable release (based on
>>>> recent discussions, it's not entirely clear whether that would be PHP
>> 7.4
>>>> or 8.0).
>>>
>>> Sounds like the RMs for 7.3 need to weigh in on this.
>>> For me I think it's worthwhile delaying two weeks, +1.
>>
>> Is there any precendent for postponing feature freeze during the (late)
>> alpha stage?
>
> This was done for the PHP 7.1 release at pretty much the same time (before
> the beta1 release it was decided to go with another alpha instead), for
> much the same reasons (pending RFCs, though I don't remember the
> specifics). See https://externals.io/message/94330 for the announcement
> mail.

Ah, thanks, Nikita!  Considering this, I'm not against delaying beta1
for two weeks and having an alpha4, provided that we do not allow any
new (i.e. not yet under discussion) RFC to target 7.3.

Stas, what do you think?

--
Christoph M. Becker

Rowan Collins

8 years ago

On 20/06/2018 22:59, Nikita Popov wrote:

> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>      https://wiki.php.net/rfc/typed_properties_v2

Hi Nikita, and Bob,

Thanks for the extremely thorough RFC. I think you've made a great case
for the decisions you've taken, and it's reassuring to see so many
edge-cases considered. In particular, the well-considered support for
references makes it feel like a complete feature. The lack of "callable"
is the only caveat that might surprise users, but I think it's
justified, because we can't actually guarantee that something that was
callable when it went in will be callable when it comes out.

One thing that I would be interested to hear, is whether any of the
groundwork laid here - particularly for typed references - would be
useful if we were to introduce typed local variables in future. I don't
want to derail the thread discussing exactly how this would work, but
does anyone have a general hunch of whether this "brings us closer", IF
we decided that was where we wanted to go?

Regards,

--
Rowan Collins
[IMSoP]

Marco Pivetta

8 years ago

I'm not sure why the mailing list is not picking up my messages, but TL:DR;
is that I spent the weekend testing all of its corners, and the patch works
flawlessly and can be pushed forward IMO.

It works consistently with current PHP semantics and significantly improves
the language, so let's make this happen :-)


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Sun, Jun 24, 2018 at 11:05 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

Nikita Popov

8 years ago

On Wed, Jun 20, 2018 at 11:59 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> Bob and I would like to present a new typed properties proposal for your
> consideration:
>
>     https://wiki.php.net/rfc/typed_properties_v2
>
> The proposal allows you to annotate properties with types, which are
> enforced at runtime. Unlike the previous RFC on this topic, the new
> proposal also supports typed static properties and references to typed
> properties.
>
> Please note that next to the main body, the RFC also contains an
> "Alternatives" section, which explores the problem space and considers
> trade-offs of different behaviors in some detail.
>
> Finally, while this RFC currently targets PHP 7.3, this is a large and
> complex proposal and we may not be able to meet the deadline, in which case
> this feature will go into the next PHP version.
>
> Regards,
> Nikita
>

Based on the feedback we received, we have decided to target PHP 7.4 for
this RFC. A main factor for this decision was that the RFC requires some
non-trivial changes to 3rd-party extensions for full compatibility. This
would put the ongoing (but nearly complete) effort to port extensions to
PHP 7.3 back to square one.

Now that the target version is decided and the last open questions in the
RFC have been resolved, we plan to open voting tomorrow.

Regards,
Nikita

PS: Thanks goes to the RMs for delaying the release schedule and providing
us with the opportunity to target PHP 7.3, even if we did not end up using
it.

Christoph Becker

8 years ago

On 16.07.2018 at 21:45, Nikita Popov wrote:

> Based on the feedback we received, we have decided to target PHP 7.4 for
> this RFC. A main factor for this decision was that the RFC requires some
> non-trivial changes to 3rd-party extensions for full compatibility. This
> would put the ongoing (but nearly complete) effort to port extensions to
> PHP 7.3 back to square one.
>
> PS: Thanks goes to the RMs for delaying the release schedule and providing
> us with the opportunity to target PHP 7.3, even if we did not end up using
> it.

Thanks for the careful decision. :)

--
Christoph M. Becker

Sara Golemon

8 years ago

On Mon, Jul 16, 2018 at 3:45 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Based on the feedback we received, we have decided to target PHP 7.4 for
> this RFC. A main factor for this decision was that the RFC requires some
> non-trivial changes to 3rd-party extensions for full compatibility. This
> would put the ongoing (but nearly complete) effort to port extensions to
> PHP 7.3 back to square one.
>

I look forward to seeing this in 7.4!

> PS: Thanks goes to the RMs for delaying the release schedule and providing
> us with the opportunity to target PHP 7.3, even if we did not end up using
> it.
>

Ultimately, that was for the other RFCs as much as for TP.  What's
important is that PHP continues moving forward.

-Sara

Zeev Suraski

8 years ago

> Based on the feedback we received, we have decided to target PHP 7.4 for this
> RFC. A main factor for this decision was that the RFC requires some non-trivial
> changes to 3rd-party extensions for full compatibility. This would put the
> ongoing (but nearly complete) effort to port extensions to PHP 7.3 back to
> square one.

As I mentioned beforehand, I think it's good it wasn't rushed into 7.3 and at the same time sorry it's not being targeted for 8.0.

> Now that the target version is decided and the last open questions in the RFC
> have been resolved, we plan to open voting tomorrow.

IMHO one of the key reasons for not putting it into 7.3 was the fact that very little discussion about the actual proposal actually happened because it arrived so late in the 7.3 release cycle.  Most of the discussion under the Typed Properties thread actually had to do with whether or not it should go into 7.3, 7.4 or 8.0 - and not about the specifics of the proposal.  I skimmed through the thread and found just a handful of responses that dealt with the specific of the proposals - most of them unanswered (unless I'm missing some internals email somehow).

With this in mind, I think that now that the meta parts are finalized, we should allow a bit more time for real meaningful discussion about the proposal to happen.  I understand that you don't want to delay this to a later time in the 7.4 process, but delaying it by a week or so will allow people to actually review the proposal in more detail without the uncertainty that surrounded it beforehand - and perhaps have their concerns addressed.  Given that 7.4's finalization date is a year away, and there are no conflicting RFCs in the queue - a week will not have any sort of negative influence on the proposal, but might have some positive impact on its contents.

Zeev

Niklas Keller

8 years ago

Zeev Suraski <zeev@zend.com> schrieb am Di., 17. Juli 2018, 00:10:

> > Based on the feedback we received, we have decided to target PHP 7.4 for
> this
> > RFC. A main factor for this decision was that the RFC requires some
> non-trivial
> > changes to 3rd-party extensions for full compatibility. This would put
> the
> > ongoing (but nearly complete) effort to port extensions to PHP 7.3 back
> to
> > square one.
>
> As I mentioned beforehand, I think it's good it wasn't rushed into 7.3 and
> at the same time sorry it's not being targeted for 8.0.
>
> > Now that the target version is decided and the last open questions in
> the RFC
> > have been resolved, we plan to open voting tomorrow.
>
> IMHO one of the key reasons for not putting it into 7.3 was the fact that
> very little discussion about the actual proposal actually happened because
> it arrived so late in the 7.3 release cycle.  Most of the discussion under
> the Typed Properties thread actually had to do with whether or not it
> should go into 7.3, 7.4 or 8.0 - and not about the specifics of the
> proposal.  I skimmed through the thread and found just a handful of
> responses that dealt with the specific of the proposals - most of them
> unanswered (unless I'm missing some internals email somehow).
>
> With this in mind, I think that now that the meta parts are finalized, we
> should allow a bit more time for real meaningful discussion about the
> proposal to happen.  I understand that you don't want to delay this to a
> later time in the 7.4 process, but delaying it by a week or so will allow
> people to actually review the proposal in more detail without the
> uncertainty that surrounded it beforehand - and perhaps have their concerns
> addressed.  Given that 7.4's finalization date is a year away, and there
> are no conflicting RFCs in the queue - a week will not have any sort of
> negative influence on the proposal, but might have some positive impact on
> its contents.
>
> Zeev
>

I'd also like to ask for a further discussion period. Seems like there is
quite some discussion going on right now.

Regards, Niklas

Nikita Popov

8 years ago

On Tue, Jul 17, 2018 at 12:10 AM, Zeev Suraski <zeev@zend.com> wrote:

> > Based on the feedback we received, we have decided to target PHP 7.4 for
> this
> > RFC. A main factor for this decision was that the RFC requires some
> non-trivial
> > changes to 3rd-party extensions for full compatibility. This would put
> the
> > ongoing (but nearly complete) effort to port extensions to PHP 7.3 back
> to
> > square one.
>
> As I mentioned beforehand, I think it's good it wasn't rushed into 7.3 and
> at the same time sorry it's not being targeted for 8.0.
>
> > Now that the target version is decided and the last open questions in
> the RFC
> > have been resolved, we plan to open voting tomorrow.
>
> IMHO one of the key reasons for not putting it into 7.3 was the fact that
> very little discussion about the actual proposal actually happened because
> it arrived so late in the 7.3 release cycle.  Most of the discussion under
> the Typed Properties thread actually had to do with whether or not it
> should go into 7.3, 7.4 or 8.0 - and not about the specifics of the
> proposal.  I skimmed through the thread and found just a handful of
> responses that dealt with the specific of the proposals - most of them
> unanswered (unless I'm missing some internals email somehow).
>
> With this in mind, I think that now that the meta parts are finalized, we
> should allow a bit more time for real meaningful discussion about the
> proposal to happen.  I understand that you don't want to delay this to a
> later time in the 7.4 process, but delaying it by a week or so will allow
> people to actually review the proposal in more detail without the
> uncertainty that surrounded it beforehand - and perhaps have their concerns
> addressed.  Given that 7.4's finalization date is a year away, and there
> are no conflicting RFCs in the queue - a week will not have any sort of
> negative influence on the proposal, but might have some positive impact on
> its contents.
>
> Zeev
>

Sure, we can wait another week. Unless the additional discussion results in
major changes to the RFC, we'll start voting next Monday (2018-07-23). In
the interest of avoiding further delays, please try to view this as a hard
deadline: If you would like to discuss some aspect of the proposal or raise
a concern, please do so now rather than on Monday morning.

Nikita

Zeev Suraski

8 years ago

On 17 Jul 2018, at 21:02, Nikita Popov <nikita.ppv@gmail.com<mailto:nikita.ppv@gmail.com>> wrote:

On Tue, Jul 17, 2018 at 12:10 AM, Zeev Suraski <zeev@zend.com<mailto:zeev@zend.com>> wrote:

> Based on the feedback we received, we have decided to target PHP 7.4 for this
> RFC. A main factor for this decision was that the RFC requires some non-trivial
> changes to 3rd-party extensions for full compatibility. This would put the
> ongoing (but nearly complete) effort to port extensions to PHP 7.3 back to
> square one.

As I mentioned beforehand, I think it's good it wasn't rushed into 7.3 and at the same time sorry it's not being targeted for 8.0.

> Now that the target version is decided and the last open questions in the RFC
> have been resolved, we plan to open voting tomorrow.

IMHO one of the key reasons for not putting it into 7.3 was the fact that very little discussion about the actual proposal actually happened because it arrived so late in the 7.3 release cycle.  Most of the discussion under the Typed Properties thread actually had to do with whether or not it should go into 7.3, 7.4 or 8.0 - and not about the specifics of the proposal.  I skimmed through the thread and found just a handful of responses that dealt with the specific of the proposals - most of them unanswered (unless I'm missing some internals email somehow).

With this in mind, I think that now that the meta parts are finalized, we should allow a bit more time for real meaningful discussion about the proposal to happen.  I understand that you don't want to delay this to a later time in the 7.4 process, but delaying it by a week or so will allow people to actually review the proposal in more detail without the uncertainty that surrounded it beforehand - and perhaps have their concerns addressed.  Given that 7.4's finalization date is a year away, and there are no conflicting RFCs in the queue - a week will not have any sort of negative influence on the proposal, but might have some positive impact on its contents.

Zeev

Sure, we can wait another week. Unless the additional discussion results in major changes to the RFC, we'll start voting next Monday (2018-07-23). In the interest of avoiding further delays, please try to view this as a hard deadline: If you would like to discuss some aspect of the proposal or raise a concern, please do so now rather than on Monday morning.

Much appreciated - thank you!

Zeev

Zeev Suraski

8 years ago

On Tue, Jul 17, 2018 at 9:02 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> Sure, we can wait another week. Unless the additional discussion results in
> major changes to the RFC, we'll start voting next Monday (2018-07-23). In
> the interest of avoiding further delays, please try to view this as a hard
> deadline: If you would like to discuss some aspect of the proposal or raise
> a concern, please do so now rather than on Monday morning.
>

I reviewed the proposal in detail - and quite detailed it is.  It seems
like you and Bob did a very thorough job here, kudos on that.

I do have 3 comments - none of them major - but I think should be addressed
nonetheless:

1. The RFC is surprisingly sparse on examples where the typed properties
are not scalar ones.  So much, in fact, that I had to check whether this is
intentional (i.e., classes are unsupported as enforced property types) or
an oversight.  Reviewing the 'Supported Types' section, while mentioning a
ClassOrInterface - isn't entirely clear, as it's unclear whether this is a
token, or something that stands for any class name or interface.
Thankfully the proposal does cover class and interface names as property
type definitions.  I would recommend to be explicit here, and say "any
class or interface name", and ideally also provide a sample of that option
in the Introduction section of the RFC.
2.  While trying to understand whether #1 was in fact supported and
reviewing the patch, I noticed that there were several comments from Dmitry
on the patch (within the pull request).  It would be nice if they were
addressed (none of them will turn the patch upside down, and as I see it
they are orthogonal to the vote).
3. The patch does bring a performance penalty, albeit quite small (every
property assignment now has to conduct type safety checks).  This does not
only affect code that uses typed properties - but also code that doesn't.
I think this should be mentioned in the RFC.  To be clear - I don't think
the penalty is substantial enough to change someone's opinion about the
merits of the proposal one way or another - but in the spirit of full
disclosure it should be there.

Zeev

Dmitry Stogov

8 years ago

I've run few benchmarks, to measure the performance penalty of this proposal.

https://gist.github.com/dstogov/b9fc0fdccfb8bf7bae121ce3d3ff1db1

In most cases real-life apps become ~1% slower. In the worst case, I got 6% slowdown (on mediawiki).

Thanks. Dmitry.

________________________________
From: Zeev Suraski <vsuraski@gmail.com>
Sent: Thursday, July 19, 2018 11:52:37 AM
To: Nikita Popov
Cc: Zeev Suraski; Internals
Subject: Re: [PHP-DEV] Re: [RFC] Typed Properties

On Tue, Jul 17, 2018 at 9:02 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> Sure, we can wait another week. Unless the additional discussion results in
> major changes to the RFC, we'll start voting next Monday (2018-07-23). In
> the interest of avoiding further delays, please try to view this as a hard
> deadline: If you would like to discuss some aspect of the proposal or raise
> a concern, please do so now rather than on Monday morning.
>

I reviewed the proposal in detail - and quite detailed it is.  It seems
like you and Bob did a very thorough job here, kudos on that.

I do have 3 comments - none of them major - but I think should be addressed
nonetheless:

1. The RFC is surprisingly sparse on examples where the typed properties
are not scalar ones.  So much, in fact, that I had to check whether this is
intentional (i.e., classes are unsupported as enforced property types) or
an oversight.  Reviewing the 'Supported Types' section, while mentioning a
ClassOrInterface - isn't entirely clear, as it's unclear whether this is a
token, or something that stands for any class name or interface.
Thankfully the proposal does cover class and interface names as property
type definitions.  I would recommend to be explicit here, and say "any
class or interface name", and ideally also provide a sample of that option
in the Introduction section of the RFC.
2.  While trying to understand whether #1 was in fact supported and
reviewing the patch, I noticed that there were several comments from Dmitry
on the patch (within the pull request).  It would be nice if they were
addressed (none of them will turn the patch upside down, and as I see it
they are orthogonal to the vote).
3. The patch does bring a performance penalty, albeit quite small (every
property assignment now has to conduct type safety checks).  This does not
only affect code that uses typed properties - but also code that doesn't.
I think this should be mentioned in the RFC.  To be clear - I don't think
the penalty is substantial enough to change someone's opinion about the
merits of the proposal one way or another - but in the spirit of full
disclosure it should be there.

Zeev

André Rømcke

8 years ago

> On 19 Jul 2018, at 13:34, Dmitry Stogov <dmitry@zend.com> wrote:
>
> I've run few benchmarks, to measure the performance penalty of this proposal.
>
>
> https://gist.github.com/dstogov/b9fc0fdccfb8bf7bae121ce3d3ff1db1
>
>
> In most cases real-life apps become ~1% slower. In the worst case, I got 6% slowdown (on mediawiki).

Nice overview.

Is there any overview of how it will improve performance for code moving from magic getters / setters to this?

Or is there interest in such a comparison?

(Context: working on a larger open source project where that is used quite a bit for type and read-only safety checks.)

Best,
André