[RFC] Typed Properties

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Marco Pivetta — view source

unread

Hi Nikita, Bob,

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.

6 years ago by Bob Weinand — view source

unread

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,

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

6 years ago by Marco Pivetta — view source

unread

Hi Bob,

__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/

6 years ago by Gabriel Caruso — view source

unread

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

6 years ago by Sara Golemon — view source

unread

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

6 years ago by Bob Weinand — view source

unread

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

6 years ago by Sara Golemon — view source

unread

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

6 years ago by Christoph M. Becker — view source

unread

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

6 years ago by Nicolas Grekas — view source

unread

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

6 years ago by Bob Weinand — view source

unread

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

6 years ago by Nicolas Grekas — view source

unread

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?

6 years ago by Bob Weinand — view source

unread

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

6 years ago by Nicolas Grekas — view source

unread

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 :)

6 years ago by Nicolas Grekas — view source

unread

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

6 years ago by Rowan Collins — view source

unread

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]

6 years ago by Stephen Reay — view source

unread

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

6 years ago by Larry Garfield — view source

unread

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.)

6 years ago by Bob Weinand — view source

unread

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

6 years ago by Patrick ALLAERT — view source

unread

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

6 years ago by Bob Weinand — view source

unread

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

6 years ago by Stanislav Malyshev — view source

unread

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

6 years ago by Dan Ackroyd — view source

unread

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

6 years ago by Sara Golemon — view source

unread

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

6 years ago by bjorn.x.larsson@telia.com — view source

unread

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

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

6 years ago by Marco Pivetta — view source

unread

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!

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Sebastian Bergmann — view source

unread

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.

6 years ago by bjorn.x.larsson@telia.com — view source

unread

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

6 years ago by Christoph M. Becker — view source

unread

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

6 years ago by shinji igarashi — view source

unread

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:

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

6 years ago by Nikita Popov — view source

unread

On Thu, Jul 5, 2018 at 1:25 PM, Christoph M. Becker cmbecker69@gmx.de
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

6 years ago by Christoph M. Becker — view source

unread

On Thu, Jul 5, 2018 at 1:25 PM, Christoph M. Becker cmbecker69@gmx.de
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

6 years ago by Sara Golemon — view source

unread

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?

It's up to a combination of internals@ opinion, and RM best-judgement.
I for one, see no issue with pushing FF out (we can do an alpha4, even
an alpha5). On the other end we have the option of reducing the
number of RCs, or pushing GA by the same delay. FTR; I'd favor
pushing GA out over shortening the RC cycle, but I wouldn't lose sleep
if we wanted to keep the GA date where it is.

-Sara

6 years ago by Sara Golemon — view source

unread

It's up to a combination of internals@ opinion, and RM best-judgement.
I for one, see no issue with pushing FF out (we can do an alpha4, even
an alpha5). On the other end we have the option of reducing the
number of RCs, or pushing GA by the same delay. FTR; I'd favor
pushing GA out over shortening the RC cycle, but I wouldn't lose sleep
if we wanted to keep the GA date where it is.

Just want to be annoying about this since the currently scheduled fork
date for PHP-7.3 is 11 days off.
1/ Do we have ANY objections to additional alpha(s) to accommodate
Typed Props? (I would propose two additional alphas)
2/ Do we actually need to hold a formal vote? (If so, that vote should
start now)

Assuming the answer to both questions is 'No'. I'd like to propose the
7.3 RMs update https://wiki.php.net/todo/php73 to reflect a new
schedule with alpha4 and alpha5 and (provisionally) only four RCs to
maintain the same GA date, but that we should revisit the topic
sometime around the new RC2 date.

-Sara

6 years ago by Christoph M. Becker — view source

unread

It's up to a combination of internals@ opinion, and RM best-judgement.
I for one, see no issue with pushing FF out (we can do an alpha4, even
an alpha5). On the other end we have the option of reducing the
number of RCs, or pushing GA by the same delay. FTR; I'd favor
pushing GA out over shortening the RC cycle, but I wouldn't lose sleep
if we wanted to keep the GA date where it is.

Just want to be annoying about this since the currently scheduled fork
date for PHP-7.3 is 11 days off.

Thanks, Sara! :)

1/ Do we have ANY objections to additional alpha(s) to accommodate
Typed Props? (I would propose two additional alphas)
2/ Do we actually need to hold a formal vote? (If so, that vote should
start now)

For me: no and no.

Assuming the answer to both questions is 'No'. I'd like to propose the
7.3 RMs update https://wiki.php.net/todo/php73 to reflect a new
schedule with alpha4 and alpha5 and (provisionally) only four RCs to
maintain the same GA date, but that we should revisit the topic
sometime around the new RC2 date.

Why should we have 2 additional alphas? In my opinion, a single
additional alpha is sufficient, and it is really important not to add
yet further features.

--
Christoph M. Becker

6 years ago by Sara Golemon — view source

unread

Why should we have 2 additional alphas? In my opinion, a single
additional alpha is sufficient, and it is really important not to add
yet further features.

Because in the best case scenario (with a single extra alpha), the RFC
is ready now, and the vote for it opens immediately. After two weeks,
we get a yes vote and we'll be right on the edge of ready for
FF/beta1. Adding that fifth alpha gives us breathing room for
something short of idealized circumstances.

First, it may be a personal thing, but I feel that the flexibility towards adding
this is very contrasty with the inflexibility shown as we headed towards the
PHP 7.0 feature freeze - inflexibility that resulted in a rushed (and IMHO wrong)
decision regarding how to implement the non-strict types.

Actually, I think Typed Props are being rushed as well, and I'm not
pleased with it, but I can also see the writing on the wall and want
to minimize the impact of that hurry (hence, pushing the timeline out
rather than having things land weeks into the beta cycle).

For the record - as I said back then - I think that the right way is to be flexible -
the dates are just dates, and are - in all honesty - not that important - it’s the severe
inconsistency that bothers me.

I agree that dates are just dates, but blithely eroding the
pre-release cycle without pushing the GA date out isn't saying "dates
are dates", it's saying "RC testing doesn't matter". I just want 7.3
to get as much baking in time as earlier releases got.

Secondly, and somewhat related - typed properties isn't a small feature.
It is, in fact, a pretty huge one. Making exceptions for a fairly minor feature
or some extra deprecation is one thing. Making an exception for something
as fundamental as that feels wrong.

Agreed, and why I haven't decided on a "yes" vote. Again, I'm not
pushing for this feature, I'm pushing for our pre-release cycle
suffering as little damage as I can manage to protect it from.

Even though Nikita's proposal and implementation look pretty solid,
something as fundamental as that should go through a substantial
active discussion period (which didn't really happen here as it wasn't
clear whether this was headed for an exceptional 7.3 addition or not) -

I'm working on the assumption that Niki still plans to bring this to
vote. Perhaps he's decide it needs to wait and this whole discussion
of extra alphas is moot. That's why I sent an email about the
subject.

and independently - should perhaps go hand-in-hand with fixing the
flaws of the non-strict types - something we can do in PHP 8.
If we do the latter, then perhaps, just perhaps, we can introduce it
hand-in-hand with typed variables - and if we do, it will be sensible
to do it at the same time and not in a gradual rollout.

And that's a decision we need to make, NOW. We need to know in the
next 10 days if we're going to move forward with a 7.3 that doesn't
contain TP, or if we're going to push out the betas until we can
solidify it. Waiting to make that decision is making a decision by
default (almost as bad as making the wrong decision).

Personally, I think even independently of typed variables, typed properties feel like an 8.0 feature, not a 7.x feature.

I probably agree with you on that. (Again, still undecided).

-Sara

6 years ago by Lester Caine — view source

unread

Personally, I think even independently of typed variables, typed properties feel like an 8.0 feature, not a 7.x feature.

I probably agree with you on that. (Again, still undecided).

The debate seems to assume that Typed Properties ARE a done deal even
without a vote? Personally I just feel all this is still going in the
wrong direction and trying to work out where to go next is still
detracting from getting new work done. In practice if I need 'typed'
anything, I need types that actually return an advantage, and
unrestricted 'int' and the like is NOT providing that!

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

6 years ago by Marco Pivetta — view source

unread

Hi Lester,

Typed properties combined with value objects (quite widespread technique)
provide a decent level of safety at this point in time.

So far, there haven't been many nay-sayers to the patch: it's OK to vote
"no" if you don't understand or don't want the feature.

Greets,

Marco

Personally, I think even independently of typed variables, typed
properties feel like an 8.0 feature, not a 7.x feature.

I probably agree with you on that. (Again, still undecided).

The debate seems to assume that Typed Properties ARE a done deal even
without a vote? Personally I just feel all this is still going in the
wrong direction and trying to work out where to go next is still
detracting from getting new work done. In practice if I need 'typed'
anything, I need types that actually return an advantage, and
unrestricted 'int' and the like is NOT providing that!

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

6 years ago by Christoph M. Becker — view source

unread

Why should we have 2 additional alphas? In my opinion, a single
additional alpha is sufficient, and it is really important not to add
yet further features.

Because in the best case scenario (with a single extra alpha), the RFC
is ready now, and the vote for it opens immediately. After two weeks,
we get a yes vote and we'll be right on the edge of ready for
FF/beta1. Adding that fifth alpha gives us breathing room for
something short of idealized circumstances.

I see!

and independently - should perhaps go hand-in-hand with fixing the
flaws of the non-strict types - something we can do in PHP 8.
If we do the latter, then perhaps, just perhaps, we can introduce it
hand-in-hand with typed variables - and if we do, it will be sensible
to do it at the same time and not in a gradual rollout.

And that's a decision we need to make, NOW. We need to know in the
next 10 days if we're going to move forward with a 7.3 that doesn't
contain TP, or if we're going to push out the betas until we can
solidify it. Waiting to make that decision is making a decision by
default (almost as bad as making the wrong decision).

ACK! How should we make this decision? A vote in the Wiki? The full
RFC process is no option anymore.

--
Christoph M. Becker

6 years ago by bjorn.x.larsson@telia.com — view source

unread

It's up to a combination of internals@ opinion, and RM best-judgement.
I for one, see no issue with pushing FF out (we can do an alpha4, even
an alpha5). On the other end we have the option of reducing the
number of RCs, or pushing GA by the same delay. FTR; I'd favor
pushing GA out over shortening the RC cycle, but I wouldn't lose sleep
if we wanted to keep the GA date where it is.

Just want to be annoying about this since the currently scheduled fork
date for PHP-7.3 is 11 days off.
1/ Do we have ANY objections to additional alpha(s) to accommodate
Typed Props? (I would propose two additional alphas)
2/ Do we actually need to hold a formal vote? (If so, that vote should
start now)

For me that's no and no.

Assuming the answer to both questions is 'No'. I'd like to propose the
7.3 RMs update https://wiki.php.net/todo/php73 to reflect a new
schedule with alpha4 and alpha5 and (provisionally) only four RCs to
maintain the same GA date, but that we should revisit the topic
sometime around the new RC2 date.

I leave this to the judgement of the RMs. I have no opinion myself,
besides I think it's a good idea to keep the GA date.

r//Björn Larsson

6 years ago by Kalle Sommer Nielsen — view source

unread

Den lør. 7. jul. 2018 kl. 10.47 skrev Björn Larsson bjorn.x.larsson@telia.com:

I leave this to the judgement of the RMs. I have no opinion myself,
besides I think it's a good idea to keep the GA date.

I agree, and an additional few weeks will make the release date very
close to the holidays, I think late November/early December is the way
to go about this.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

6 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Friday, July 6, 2018 10:36 PM
To: Christoph M. Becker cmbecker69@gmx.de
Cc: Nikita Popov nikita.ppv@gmail.com; stas@php.net; Björn Larsson
bjorn.x.larsson@telia.com; Dan Ackroyd danack@basereality.com;
Stanislav Malyshev smalyshev@gmail.com; Marco Pivetta
ocramius@gmail.com; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Typed Properties

Just want to be annoying about this since the currently scheduled fork date for
PHP-7.3 is 11 days off.
1/ Do we have ANY objections to additional alpha(s) to accommodate Typed
Props? (I would propose two additional alphas) 2/ Do we actually need to hold a
formal vote? (If so, that vote should start now)

Sara,

I do see a couple of issues here.

First, it may be a personal thing, but I feel that the flexibility towards adding this is very contrasty with the inflexibility shown as we headed towards the PHP 7.0 feature freeze - inflexibility that resulted in a rushed (and IMHO wrong) decision regarding how to implement the non-strict types. For the record - as I said back then - I think that the right way is to be flexible - the dates are just dates, and are - in all honesty - not that important - it’s the severe inconsistency that bothers me.

Secondly, and somewhat related - typed properties isn't a small feature. It is, in fact, a pretty huge one. Making exceptions for a fairly minor feature or some extra deprecation is one thing. Making an exception for something as fundamental as that feels wrong.

Even though Nikita's proposal and implementation look pretty solid, something as fundamental as that should go through a substantial active discussion period (which didn't really happen here as it wasn't clear whether this was headed for an exceptional 7.3 addition or not) - and independently - should perhaps go hand-in-hand with fixing the flaws of the non-strict types - something we can do in PHP 8. If we do the latter, then perhaps, just perhaps, we can introduce it hand-in-hand with typed variables - and if we do, it will be sensible to do it at the same time and not in a gradual rollout. Personally, I think even independently of typed variables, typed properties feel like an 8.0 feature, not a 7.x feature.

Zeev

6 years ago by bjorn.x.larsson@telia.com — view source

unread

Den 2018-07-07 kl. 23:12, skrev Zeev Suraski:

-----Original Message-----
From:php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Friday, July 6, 2018 10:36 PM
To: Christoph M. Beckercmbecker69@gmx.de
Cc: Nikita Popovnikita.ppv@gmail.com;stas@php.net; Björn Larsson
bjorn.x.larsson@telia.com; Dan Ackroyddanack@basereality.com;
Stanislav Malyshevsmalyshev@gmail.com; Marco Pivetta
ocramius@gmail.com; PHP internalsinternals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Typed Properties

Just want to be annoying about this since the currently scheduled fork date for
PHP-7.3 is 11 days off.
1/ Do we have ANY objections to additional alpha(s) to accommodate Typed
Props? (I would propose two additional alphas) 2/ Do we actually need to hold a
formal vote? (If so, that vote should start now)
Sara,

I do see a couple of issues here.

First, it may be a personal thing, but I feel that the flexibility towards adding this is very contrasty with the inflexibility shown as we headed towards the PHP 7.0 feature freeze - inflexibility that resulted in a rushed (and IMHO wrong) decision regarding how to implement the non-strict types. For the record - as I said back then - I think that the right way is to be flexible - the dates are just dates, and are - in all honesty - not that important - it’s the severe inconsistency that bothers me.

Secondly, and somewhat related - typed properties isn't a small feature. It is, in fact, a pretty huge one. Making exceptions for a fairly minor feature or some extra deprecation is one thing. Making an exception for something as fundamental as that feels wrong.

Even though Nikita's proposal and implementation look pretty solid, something as fundamental as that should go through a substantial active discussion period (which didn't really happen here as it wasn't clear whether this was headed for an exceptional 7.3 addition or not) - and independently - should perhaps go hand-in-hand with fixing the flaws of the non-strict types - something we can do in PHP 8. If we do the latter, then perhaps, just perhaps, we can introduce it hand-in-hand with typed variables - and if we do, it will be sensible to do it at the same time and not in a gradual rollout. Personally, I think even independently of typed variables, typed properties feel like an 8.0 feature, not a 7.x feature.

Zeev

You do have a point here about combining this with 8.0. I think it
then would be great if an RFC like the one for 7.0 shows up soon.

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

If 8.0 drags on I think it's beneficial to have this feature earlier, like
now ;-)

I was a bit surprised myself that the discussion has not been so active.
On the other hand typed properties was up for discussion earlier and
much of the disadvantages has now been remedied in this proposal.
Given the high quality of this RFC and earlier discussions I personally
felt it was not so much to ponder about.

I can see some advantages with having this feature in a 7.x release:

It leaves more space for doing other stuff in 8.0 given that core
resources are scarce.
It adds a lot of value to 7.3, which is not packed with features.

r//Björn Larsson

6 years ago by Stanislav Malyshev — view source

unread

Hi!

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?

Sorry for late answer, I've been behind my emails due to being extremely
busy.

I think we should go for 7.4 with this and take our time. Typed
properties is not some small deprecation or new function. It's a big
thing. If we rush it, it will become messy, there's no way around it. I
know about 7.4 "deprecations only" plans, but my personal take on this
it's too early to close on that, and between the choices of "fat 7.4"
and "rushing TP into 7.3 right now" I am firmly on the side of the former.

--
Stas Malyshev
smalyshev@gmail.com

6 years ago by Rowan Collins — view source

unread

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]

6 years ago by Marco Pivetta — view source

unread

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
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]

6 years ago by Nikita Popov — view source

unread

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.

6 years ago by Christoph M. Becker — view source

unread

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

6 years ago by Sara Golemon — view source

unread

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

6 years ago by Zeev Suraski — view source

unread

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

6 years ago by Niklas Keller — view source

unread

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

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Zeev Suraski — view source

unread

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:

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.
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).
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

6 years ago by andre.romcke@ez.no — view source

unread

-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Friday, July 6, 2018 10:36 PM
To: Christoph M. Becker cmbecker69@gmx.de
Cc: Nikita Popov nikita.ppv@gmail.com; stas@php.net; Björn Larsson
bjorn.x.larsson@telia.com; Dan Ackroyd danack@basereality.com;
Stanislav Malyshev smalyshev@gmail.com; Marco Pivetta
ocramius@gmail.com; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Typed Properties

Just want to be annoying about this since the currently scheduled fork date for
PHP-7.3 is 11 days off.
1/ Do we have ANY objections to additional alpha(s) to accommodate Typed
Props? (I would propose two additional alphas) 2/ Do we actually need to hold a
formal vote? (If so, that vote should start now)

Sara,

I do see a couple of issues here.

First, it may be a personal thing, but I feel that the flexibility towards adding this is very contrasty with the inflexibility shown as we headed towards the PHP 7.0 feature freeze - inflexibility that resulted in a rushed (and IMHO wrong) decision regarding how to implement the non-strict types. For the record - as I said back then - I think that the right way is to be flexible - the dates are just dates, and are - in all honesty - not that important - it’s the severe inconsistency that bothers me.

Regardless of typed properties this sounds like something that should be tackled as an independent topic. (It could in theory, if accepted, be a new type flag introduced in 7.4 and made default in 8.0 that affect all type usage consistently.)

Secondly, and somewhat related - typed properties isn't a small feature. It is, in fact, a pretty huge one. Making exceptions for a fairly minor feature or some extra deprecation is one thing. Making an exception for something as fundamental as that feels wrong.

Even though Nikita's proposal and implementation look pretty solid, something as fundamental as that should go through a substantial active discussion period (which didn't really happen here as it wasn't clear whether this was headed for an exceptional 7.3 addition or not) - and independently - should perhaps go hand-in-hand with fixing the flaws of the non-strict types - something we can do in PHP 8. If we do the latter, then perhaps, just perhaps, we can introduce it hand-in-hand with typed variables - and if we do, it will be sensible to do it at the same time and not in a gradual rollout. Personally, I think even independently of typed variables, typed properties feel like an 8.0 feature, not a 7.x feature.

While I agree this is big, (from user land it’s fantastic), and should only go in if solid. It does contradict your argument the other day about being careful what to push into 8.0 scope as core resources are scarce.

So if we look at it from that perspective, then spreading the risk is essentially safer.

6 years ago by Marco Pivetta — view source

unread

It's been a few weeks since this has first landed here, and we're just
wasting time in relatively silly discussions at this point:

As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you don't have confidence in something related to it, please
write a test case and help out.
can we get a yes/no from the RMs on whether we'll have the time window
to (potentially) get this voted and (if passed) merged? Shoot out a mail
with the decision, please. We could have a vote for which version to
include this in, if that's really such a big issue.
can we split out discussions on 8.0 scope? Minor versions are indeed for
features. If PHP 8.0 lacks interesting/marketing features, that's a
different story.
Nikita/Bob: can this be voted upon right after the RMs have taken a
decision? Anything blocking missing?
Is the reference issue reported by Nicolas a blocker? Nicolas, can you
clarify here?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Friday, July 6, 2018 10:36 PM
To: Christoph M. Becker cmbecker69@gmx.de
Cc: Nikita Popov nikita.ppv@gmail.com; stas@php.net; Björn Larsson
bjorn.x.larsson@telia.com; Dan Ackroyd danack@basereality.com;
Stanislav Malyshev smalyshev@gmail.com; Marco Pivetta
ocramius@gmail.com; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Typed Properties

Just want to be annoying about this since the currently scheduled fork
date for
PHP-7.3 is 11 days off.
1/ Do we have ANY objections to additional alpha(s) to accommodate
Typed
Props? (I would propose two additional alphas) 2/ Do we actually need
to hold a
formal vote? (If so, that vote should start now)

Sara,

I do see a couple of issues here.

First, it may be a personal thing, but I feel that the flexibility
towards adding this is very contrasty with the inflexibility shown as we
headed towards the PHP 7.0 feature freeze - inflexibility that resulted in
a rushed (and IMHO wrong) decision regarding how to implement the
non-strict types. For the record - as I said back then - I think that the
right way is to be flexible - the dates are just dates, and are - in all
honesty - not that important - it’s the severe inconsistency that bothers
me.

Regardless of typed properties this sounds like something that should be
tackled as an independent topic. (It could in theory, if accepted, be a new
type flag introduced in 7.4 and made default in 8.0 that affect all type
usage consistently.)

Secondly, and somewhat related - typed properties isn't a small
feature. It is, in fact, a pretty huge one. Making exceptions for a
fairly minor feature or some extra deprecation is one thing. Making an
exception for something as fundamental as that feels wrong.

Even though Nikita's proposal and implementation look pretty solid,
something as fundamental as that should go through a substantial active
discussion period (which didn't really happen here as it wasn't clear
whether this was headed for an exceptional 7.3 addition or not) - and
independently - should perhaps go hand-in-hand with fixing the flaws of the
non-strict types - something we can do in PHP 8. If we do the latter, then
perhaps, just perhaps, we can introduce it hand-in-hand with typed
variables - and if we do, it will be sensible to do it at the same time and
not in a gradual rollout. Personally, I think even independently of typed
variables, typed properties feel like an 8.0 feature, not a 7.x feature.

While I agree this is big, (from user land it’s fantastic), and should
only go in if solid. It does contradict your argument the other day about
being careful what to push into 8.0 scope as core resources are scarce.

So if we look at it from that perspective, then spreading the risk is
essentially safer.

6 years ago by Nicolas Grekas — view source

unread

2018-07-10 11:18 GMT+02:00 Marco Pivetta ocramius@gmail.com:

It's been a few weeks since this has first landed here, and we're just
wasting time in relatively silly discussions at this point:

As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you don't have confidence in something related to it, please
write a test case and help out.

can we get a yes/no from the RMs on whether we'll have the time window
to (potentially) get this voted and (if passed) merged? Shoot out a mail
with the decision, please. We could have a vote for which version to
include this in, if that's really such a big issue.

can we split out discussions on 8.0 scope? Minor versions are indeed for
features. If PHP 8.0 lacks interesting/marketing features, that's a
different story.

Nikita/Bob: can this be voted upon right after the RMs have taken a
decision? Anything blocking missing?

Is the reference issue reported by Nicolas a blocker? Nicolas, can you
clarify here?

I'm definitely ith you on this one Marco, typed properties is something
userland asks since a long time and postponing it to 8.0 for "marketing"
reasons might be very frustrating (well, we'll deal with that if it happens
:) )

But technically, it feels almost ready.

The reference issue looks "easy" to fix(esp. when its not me doing it yes
;) ). It'd be better to have it at the same time, but I can wait the next
version as I don't want to be the one with a blocker here, and also because
I can write a "degraded mode" for now if that's the plan.

Nicolas

6 years ago by Marco Pivetta — view source

unread

On Tue, Jul 10, 2018 at 12:21 PM, Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

I'm definitely ith you on this one Marco, typed properties is something
userland asks since a long time and postponing it to 8.0 for "marketing"
reasons might be very frustrating (well, we'll deal with that if it happens
:) )

But technically, it feels almost ready.

The reference issue looks "easy" to fix(esp. when its not me doing it yes
;) ). It'd be better to have it at the same time, but I can wait the next
version as I don't want to be the one with a blocker here, and also because
I can write a "degraded mode" for now if that's the plan.

The important bit is to not have functionality that blocks userland
scenarios that previously worked.
If the try-catch works, then we can surely roll with it.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

6 years ago by Zeev Suraski — view source

unread

On Tue, Jul 10, 2018 at 1:22 PM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:

2018-07-10 11:18 GMT+02:00 Marco Pivetta ocramius@gmail.com:

It's been a few weeks since this has first landed here, and we're just
wasting time in relatively silly discussions at this point:

As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you don't have confidence in something related to it,
please
write a test case and help out.

can we get a yes/no from the RMs on whether we'll have the time window
to (potentially) get this voted and (if passed) merged? Shoot out a
mail
with the decision, please. We could have a vote for which version to
include this in, if that's really such a big issue.

can we split out discussions on 8.0 scope? Minor versions are indeed
for
features. If PHP 8.0 lacks interesting/marketing features, that's a
different story.

Nikita/Bob: can this be voted upon right after the RMs have taken a
decision? Anything blocking missing?

Is the reference issue reported by Nicolas a blocker? Nicolas, can you
clarify here?

I'm definitely ith you on this one Marco, typed properties is something
userland asks since a long time and postponing it to 8.0 for "marketing"
reasons might be very frustrating (well, we'll deal with that if it happens
:) )

For the sake of those who weren't reading the discussion on the other
thread - the reason I believe it shouldn't go into 7.3 as well as the
reasons why I think this should be discussed for 8.0 are hardly just
'marketing' reasons, although I absolutely do think that decisions like
this (which version a certain feature goes into) is not exclusively or even
primarily a technical decision.

The reasons I stated were:
"the little time we have left, the little concrete discussion that happened
so far as a result, the inconsistency of allowing such a vote to push out
feature freeze, the scope of this feature being a lot more suitable for a
major release, and our inability to fix/improve other related elements at
the same time"

I've also given several examples - some of them arguably quite bigger than
this proposal - where we sat on code for a very long time (multiple years
even) in order for it to be included in a major version, and not a minor
one (phpng, JIT, FFI) even though technically they could go into the next
available minor.

Zeev

6 years ago by mail@pmmaga.net — view source

unread

I've also given several examples - some of them arguably quite bigger than
this proposal - where we sat on code for a very long time (multiple years
even) in order for it to be included in a major version, and not a minor
one (phpng, JIT, FFI) even though technically they could go into the next
available minor.

Hi,

I'm trying to understand this argument better but there is something I'm
missing. Why would a feature like JIT (which would be transparent to the
user AFAIK) need to wait for a major other than marketing reasons?
Sorry in advance for the slightly off-topic question.

Regards,
Pedro

6 years ago by Zeev Suraski — view source

unread

I've also given several examples - some of them arguably quite bigger than
this proposal - where we sat on code for a very long time (multiple years
even) in order for it to be included in a major version, and not a minor
one (phpng, JIT, FFI) even though technically they could go into the next
available minor.

Hi,

I'm trying to understand this argument better but there is something I'm
missing. Why would a feature like JIT (which would be transparent to the
user AFAIK) need to wait for a major other than marketing reasons?
Sorry in advance for the slightly off-topic question.

Major versions are in many respects "marketing" events. They're an
indicator that big changes have happened in the language, big enough to
warrant a change in the major version.
It's a relatively recent evolution that we decided to only make it possible
to break compatibility in major versions (and it's a very positive
evolution, without a doubt), but either way - compatibility breakage has
never been the motivating factor behind a major release. Major releases
enable compatibility breakage, not the other way around.
Major features have always gone into major releases (with one notable
exception - PHP 5.3, which many argue was a de-facto major release).

While 'marketing' always played a role in designating a certain version as
major - getting people more motivated to upgrade, bring positive vibes and
attention around the language, etc. (as was the case with 7.0) - since the
formal release process and the policy change to only allow compatibility
breakage in major versions - these compatibility breakages actually, to a
large degree, 'piggyback' on the major new features. To make it more real

what would the migration to PHP 7 look like if it was all about the
compatibility breakages, and not the performance boosts or for that matter
scalar type hints? Both of these (performance boosts and scalar type
hints) could easily go into 5.7 from a purely technical perspective.

Zeev

6 years ago by Nicolas Grekas — view source

unread

Le mar. 10 juil. 2018 à 14:56, Zeev Suraski vsuraski@gmail.com a écrit :

I've also given several examples - some of them arguably quite bigger
than
this proposal - where we sat on code for a very long time (multiple years
even) in order for it to be included in a major version, and not a minor
one (phpng, JIT, FFI) even though technically they could go into the next
available minor.

Hi,

I'm trying to understand this argument better but there is something I'm
missing. Why would a feature like JIT (which would be transparent to the
user AFAIK) need to wait for a major other than marketing reasons?
Sorry in advance for the slightly off-topic question.

Major versions are in many respects "marketing" events. They're an
indicator that big changes have happened in the language, big enough to
warrant a change in the major version.
It's a relatively recent evolution that we decided to only make it
possible to break compatibility in major versions (and it's a very positive
evolution, without a doubt), but either way - compatibility breakage has
never been the motivating factor behind a major release. Major releases
enable compatibility breakage, not the other way around.
Major features have always gone into major releases (with one notable
exception - PHP 5.3, which many argue was a de-facto major release).

While 'marketing' always played a role in designating a certain version as
major - getting people more motivated to upgrade, bring positive vibes and
attention around the language, etc. (as was the case with 7.0) - since the
formal release process and the policy change to only allow compatibility
breakage in major versions - these compatibility breakages actually, to a
large degree, 'piggyback' on the major new features. To make it more real

what would the migration to PHP 7 look like if it was all about the
compatibility breakages, and not the performance boosts or for that matter

scalar type hints? Both of these (performance boosts and scalar type
hints) could easily go into 5.7 from a purely technical perspective.

Zeev

Just to clarify my previous statement: marketing is a good reason to bump a
major version. Doing so creates momentum after the release and motivation
before.

I just don't agree that typed properties are part of that. They are a
really natural and important feature, but not one that will allow anyone to
do anything new that wasn't possible before.
JIT and/or async are game changers. They don't play in the same category to
me.
Others might disagree of course, and I don't want to minimize their
importance nor the work of Nikita and Bob. Kudos to them actually.

Nicolas

6 years ago by Larry Garfield — view source

unread

I've also given several examples - some of them arguably quite bigger
than
this proposal - where we sat on code for a very long time (multiple years
even) in order for it to be included in a major version, and not a minor
one (phpng, JIT, FFI) even though technically they could go into the next
available minor.

Hi,

I'm trying to understand this argument better but there is something I'm
missing. Why would a feature like JIT (which would be transparent to the
user AFAIK) need to wait for a major other than marketing reasons?
Sorry in advance for the slightly off-topic question.

Major versions are in many respects "marketing" events. They're an
indicator that big changes have happened in the language, big enough to
warrant a change in the major version.
It's a relatively recent evolution that we decided to only make it possible
to break compatibility in major versions (and it's a very positive
evolution, without a doubt), but either way - compatibility breakage has
never been the motivating factor behind a major release. Major releases
enable compatibility breakage, not the other way around.
Major features have always gone into major releases (with one notable
exception - PHP 5.3, which many argue was a de-facto major release).

While 'marketing' always played a role in designating a certain version as
major - getting people more motivated to upgrade, bring positive vibes and
attention around the language, etc. (as was the case with 7.0) - since the
formal release process and the policy change to only allow compatibility
breakage in major versions - these compatibility breakages actually, to a
large degree, 'piggyback' on the major new features. To make it more real

what would the migration to PHP 7 look like if it was all about the
compatibility breakages, and not the performance boosts or for that matter

scalar type hints? Both of these (performance boosts and scalar type
hints) could easily go into 5.7 from a purely technical perspective.

Zeev

While the marketing angle is valid, Zeev, it seems predicated on the idea that
there won't be any other major new-and-cool features developed between now and
8.0. I'm reasonably confident that someone will find some user-facing
exciting thing to improve between now and 2020. I know some people have plans
they're already working on.

Conceptually, as Nicolas and you have both hinted at, PHP 7.x is the series
where "typing got real". From a user-facing/marketing perspective 7.x is all
about performance and typing. That's the through line. Including typed
properties in that makes logical sense, marketing-wise, and would be a fitting
capstone to the 7.x series in that regard.

That's true regardless of whether typed properties go into 7.3 or 7.4; if
given the timing they need to wait for 7.4 to have some extra polish done
that's entirely reasonable, IMO, and doesn't change the underlying point.

However, mixing "no new features in 7.4/8.0, just the engine changes" with "we
need a big showy thing in 8.0 to help sell it", er, feels like a
contradiction. It makes it sound more like "borrowing" a feature from 7.3
(typed properties) for 8.0 for purely marketing purposes, and then also
blocking any other features, so that we know 2 years out "the only interesting
thing in 8.x will be typed properties, because that was written when 8.x was
still just a twinkle in the eye but we sat on it". That feels very
disingenuous.

I am sure that's not your intent but those two statements together ("minimize
features for 8.0" and "save this feature for 8.0 for marketing") just don't
fit together in my mind in a nice way.

--Larry Garfield

6 years ago by Zeev Suraski — view source

unread

On Tue, Jul 10, 2018 at 10:19 PM Larry Garfield larry@garfieldtech.com
wrote:

While the marketing angle is valid, Zeev, it seems predicated on the idea
that
there won't be any other major new-and-cool features developed between now
and
8.0. I'm reasonably confident that someone will find some user-facing
exciting thing to improve between now and 2020. I know some people have
plans
they're already working on.

We can agree to disagree, but effectively turning PHP into an
optionally-typed language - which Nikita's patch does a HUGE step towards
(IMHO a much bigger one than scalar type hints did at the time) is more or
less a singular event.
And no, I'm absolutely not encouraging us to come up with additional
language-changing features just for the sake of marketing - there's a world
of difference between timing the rollout schedule of what we intend to roll
out anyway, and adding extra bells and whistles just to make the new
version attractive.

Conceptually, as Nicolas and you have both hinted at, PHP 7.x is the series

where "typing got real". From a user-facing/marketing perspective 7.x is
all
about performance and typing. That's the through line. Including typed
properties in that makes logical sense, marketing-wise, and would be a
fitting
capstone to the 7.x series in that regard.

I didn't hint at that, at least not intentionally (I'd say 90-95% of the
feedback I've seen for PHP 7 was about performance, and 5-10% was pretty
much everything else, but that's beside the point).
What's on point is that new or improved capabilities are the draw into new
versions. The more (sensible!) of those you have, the better. Wasting our
'ammo' on the 7.x line at this point is, IMHO, a mistake. I guess I have
much higher levels of self control and patience - as this is precisely what
we're not going to do with the stuff we've been working on (JIT, FFI, and
phpng in the past).

However, mixing "no new features in 7.4/8.0, just the engine changes" with
"we

need a big showy thing in 8.0 to help sell it", er, feels like a

contradiction.

Maybe it feels that way, but it really isn't. I'm not sure whether you've
had the luxury of contributing to the PHP engine, but working on two
simultaneous active branches with substantial data structure differences is
an unholy mess (it's also way, way worse than working on two branches of an
average PHP project). Even if all of the developers are focused on PHP 8
it's going to be a remarkably difficult feat to achieve. Throwing in
another parallel version that we'll need to work on at the same time is
shooting ourselves in the foot.

It makes it sound more like "borrowing" a feature from 7.3

(typed properties) for 8.0 for purely marketing purposes, and then also
blocking any other features, so that we know 2 years out "the only
interesting
thing in 8.x will be typed properties, because that was written when 8.x
was
still just a twinkle in the eye but we sat on it". That feels very
disingenuous.

Please don't put words in my mouth and then call them disingenuous :)
I did not say we should 'block any other features'. In fact, in my
blueprint for PHP 8 - I said it's clear to me we're likely to see
additional ideas that will be proposed for PHP 8. It's an extra feature
release that will divide our resources that I'm arguing against.

My logic is quite simple:

Something as big as Typed Properties shouldn't be a last minute, rushed
RFC. Really - any RFC shouldn't - but in particular major language changes.
We should not have a 7.4 that divides our resources(*); Much like with
5.6 -> 7.0, we should focus on one feature version at a time.
We're better off saving Typed Properties for 8.0 as another draw - and
we can also make it better by that timeline (a comprehensive typing
solution, and not an incremental one).

I am sure that's not your intent but those two statements together

("minimize
features for 8.0" and "save this feature for 8.0 for marketing") just
don't
fit together in my mind in a nice way.

Where did I say we should minimize features for 8.0?

Zeev

6 years ago by Levi Morrison — view source

unread

My logic is quite simple:

Something as big as Typed Properties shouldn't be a last minute, rushed
RFC. Really - any RFC shouldn't - but in particular major language changes.

I have seen this sentiment expressed elsewhere. I want to personally
affirm that Nikita and Bob have been working hard on this for a long
time. This is not a last minute change being rushed. They have been
quite thorough and have discovered and fixed many edge cases that I
suspect other authors would not have found or would have ignored. Yes,
it is being voted on in the narrow gap between first alphas and
feature freeze but that does not mean it is rushed.

6 years ago by Marco Pivetta — view source

unread

My logic is quite simple:

Something as big as Typed Properties shouldn't be a last minute,
rushed
RFC. Really - any RFC shouldn't - but in particular major language
changes.

I have seen this sentiment expressed elsewhere. I want to personally
affirm that Nikita and Bob have been working hard on this for a long
time. This is not a last minute change being rushed. They have been
quite thorough and have discovered and fixed many edge cases that I
suspect other authors would not have found or would have ignored. Yes,
it is being voted on in the narrow gap between first alphas and
feature freeze but that does not mean it is rushed.

Ack, and it is such a massive improvement that pushing it back now would
simply delay a very huge jump (forward) in ecosystem quality at large for
more than a year.

Bob and Nikita got it right, they made something well thought out, well
tested, and previously already discussed: give the vote a chance, add a
sub-vote for which version to target, if required.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

6 years ago by Zeev Suraski — view source

unread

My logic is quite simple:

Something as big as Typed Properties shouldn't be a last minute,
rushed
RFC. Really - any RFC shouldn't - but in particular major language
changes.

I have seen this sentiment expressed elsewhere. I want to personally
affirm that Nikita and Bob have been working hard on this for a long
time. This is not a last minute change being rushed. They have been
quite thorough and have discovered and fixed many edge cases that I
suspect other authors would not have found or would have ignored. Yes,
it is being voted on in the narrow gap between first alphas and
feature freeze but that does not mean it is rushed.

It is being rushed as far as the RFC process & discussions around it are
concerned - that's what I meant. I did not dispute for a second that the
patch looks thoroughly thought out and a lot of effort went into it - it's
very evident and I acknowledged it already.

Zeev

6 years ago by Levi Morrison — view source

unread

It is being rushed as far as the RFC process & discussions around it are concerned - that's what I meant.

I do not agree with this either. This has been previously discussed,
they have given it an ample discussion period, and it seems the only
reason it's not being voted on is because people don't want them to.

6 years ago by Zeev Suraski — view source

unread

It is being rushed as far as the RFC process & discussions around it are
concerned - that's what I meant.

I do not agree with this either. This has been previously discussed,
they have given it an ample discussion period, and it seems the only
reason it's not being voted on is because people don't want them to.

The only time I've heard about this was slightly under 3 weeks ago when
Nikita sent this RFC to internals - where he himself alluded to the fact
that this is "a large and complex proposal that may not be able to make the
deadline". To be clear, introducing such an RFC for discussion (a large
and complex one) after alphas have been released as opposed to months
before alphas are released constitutes as 'rushed' in my book, and
apparently in the books of others as well. You don't have to agree of
course as we're all obviously entitled to our own opinions...

Zeev

6 years ago by Sara Golemon — view source

unread

It is being rushed as far as the RFC process & discussions around it are concerned - that's what I meant.

I do not agree with this either. This has been previously discussed,
they have given it an ample discussion period, and it seems the only
reason it's not being voted on is because people don't want them to.

Well... it's not being voted on because, despite being six days till
the originally planned feature freeze date, neither sponsor has opened
a vote.

-Sara

6 years ago by Stas Malyshev — view source

unread

Hi!

Well... it's not being voted on because, despite being six days till
the originally planned feature freeze date, neither sponsor has opened
a vote.

And I think it's a good thing. Both for selfish reasons (I haven't
actually have the time to read the proposal and the mail thread
properly yet, though I might be able to get to it next week) and for
procedural reasons - we're already in release process, we shouldn't be
voting on one of the biggest features in years this late. For me it
just doesn't feel right.

6 years ago by Rowan Collins — view source

unread

My logic is quite simple:

Something as big as Typed Properties shouldn't be a last minute,
rushed
RFC. Really - any RFC shouldn't - but in particular major language
changes.

I have seen this sentiment expressed elsewhere. I want to personally
affirm that Nikita and Bob have been working hard on this for a long
time. This is not a last minute change being rushed. They have been
quite thorough and have discovered and fixed many edge cases that I
suspect other authors would not have found or would have ignored. Yes,
it is being voted on in the narrow gap between first alphas and
feature freeze but that does not mean it is rushed.

They have indeed discovered many edge cases, and the RFC is extremely
thorough. But by the same token, they have made judgement calls about the
best way to handle some of those edge cases, and the RFC is 8000 words
long.

That's a lot of information for the rest of us to digest, and it's not just
trivia: accepting any implementation of this feature means making some
far-reaching decisions for the future typing functionality of the language.
For instance, I think the initialisation requirements for non-nullable
properties deserve a discussion in their own right, but I haven't yet had
time to write up my thoughts.

This isn't about rejecting the hard work that has gone into this; it's
about making sure there isn't some tweak we want to make before people
start building code that relies on it.

[Incidentally, I just noticed that we have both
https://wiki.php.net/rfc/typed-properties-v2 and
https://wiki.php.net/rfc/typed_properties_v2 - should this actually have
been "3.0"?]

Regards,

Rowan Collins
[IMSoP]

6 years ago by Nikita Popov — view source

unread

It's been a few weeks since this has first landed here, and we're just
wasting time in relatively silly discussions at this point:

As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you don't have confidence in something related to it, please
write a test case and help out.

Thanks a lot for your tests and feedback!

can we get a yes/no from the RMs on whether we'll have the time window
to (potentially) get this voted and (if passed) merged? Shoot out a mail
with the decision, please. We could have a vote for which version to
include this in, if that's really such a big issue.

can we split out discussions on 8.0 scope? Minor versions are indeed for
features. If PHP 8.0 lacks interesting/marketing features, that's a
different story.

Nikita/Bob: can this be voted upon right after the RMs have taken a
decision? Anything blocking missing?

I've just updated the RFC with the last major change (switch to the "no
intrinsic types" alternative for reference handling). Apart from some minor
tweaks (maybe add a bit more information on how the implementation works)
the RFC itself should be about ready for voting.

Even if the RMs decide that this cannot go into PHP 7.3, we'd still like to
start voting on this RFC soon (in the next few days).

Is the reference issue reported by Nicolas a blocker? Nicolas, can you

clarify here?

My plan for the reference reflection would be to write a separate RFC.
While typed properties make this more important, the feature itself is
really independent, and while we could slip it through as part of this RFC,
I think that this problem has a large enough design space that we should
discuss it separately.

Nikita

6 years ago by Christoph M. Becker — view source

unread

I've just updated the RFC with the last major change (switch to the "no
intrinsic types" alternative for reference handling). Apart from some minor
tweaks (maybe add a bit more information on how the implementation works)
the RFC itself should be about ready for voting.

Even if the RMs decide that this cannot go into PHP 7.3, we'd still like to
start voting on this RFC soon (in the next few days).

After consulting with other release managers, I would ask you not to
target PHP 7.3, because we're already in alpha stage, the changes for
feature are quite comprehensive, and affect extensions in a subtle way[1]:

| The other are changes to reference assignments. These are not
| necessary to build against PHP 7.3, but are needed to ensure the
| behavior is fully correct.

[1] https://wiki.php.net/rfc/typed_properties_v2#impact_on_extensions

--
Christoph M. Becker

6 years ago by Stanislav Malyshev — view source

unread

Hi!

As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you don't have confidence in something related to it, please
write a test case and help out.

It sounds like you are talking about "this patch" as if everything were
already done deal, all discussions are done, all decisions are made, all
implementations are finished, and the only thing we are left to decide
is when to press the "commit" button. Isn't it a bit early for this in
this stage to declare it done?

Stas Malyshev
smalyshev@gmail.com

6 years ago by Marco Pivetta — view source

unread

Nope

Hi!

As I said earlier, this patch has already been tested against some
extremely tricky scenarios, so from a userland perspective it is safe for
inclusion. If you don't have confidence in something related to it,
please
write a test case and help out.

It sounds like you are talking about "this patch" as if everything were
already done deal, all discussions are done, all decisions are made, all
implementations are finished, and the only thing we are left to decide
is when to press the "commit" button. Isn't it a bit early for this in
this stage to declare it done?

Stas Malyshev
smalyshev@gmail.com

6 years ago by Zeev Suraski — view source

unread

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.

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

6 years ago by Dmitry Stogov — view source

unread

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.

6 years ago by andre.romcke@ez.no — view source

unread

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é

[RFC] Typed Properties

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

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Regards,

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

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL