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,
Hi internals,
Bob and I would like to present a new typed properties proposal for your
consideration:https://wiki.php.net/rfc/typed_properties_v2The 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.
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 PropertiesHi 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
8f4133a54808d5d7031564%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6
36651330591392793&sdata=M70Asi8WqXbP6icXeVsdsBuI1GiK9UjgHj9EoZHX4%2Bg
%3D&reserved=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,
NikitaThis 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
__getkink, 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
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
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
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
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 PropertiesOn 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
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
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
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
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 PropertiesHi 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
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?
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
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 :)
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
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 withget_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]
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
Hi internals,
Bob and I would like to present a new typed properties proposal for your
consideration:https://wiki.php.net/rfc/typed_properties_v2The 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.)
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
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_v2https://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
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 PropertiesMy 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
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
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
I think it's better not
to feel pressured by the deadline for 7.3The 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
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
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!
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.3The 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
As such, I think that this feature can only go into 7.3 if the release
schedule is adjusted. Extending the schedule by another 2-week alpha cycle
would be sufficient to land this proposal in PHP 7.3.
+1
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.3The 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
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.3The 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
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.3The 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
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.3The 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
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
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
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
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
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
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
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 - G8HFLContact - 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
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
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
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
-----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 PropertiesJust 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
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 PropertiesJust 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.
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
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
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]
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]
Hi internals,
Bob and I would like to present a new typed properties proposal for your
consideration:https://wiki.php.net/rfc/typed_properties_v2The 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.
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
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
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
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
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
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