# [RFC][Vote] Typed Properties - Thread: https://externals.io/message/93858 - Original archive: https://news-web.php.net/php.internals/93858 - Started by Joe Watkins on 2016-06-10T10:38:04+00:00 - Messages: 60 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/93858.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #93858 — Joe Watkins — 2016-06-10T10:38:04+00:00 URL: https://externals.io/message/93858#93858 Afternoon internals, The vote for typed properties has been restarted. Please take part: https://wiki.php.net/rfc/typed-properties Cheers Joe --- ## #93859 — Dmitry Stogov — 2016-06-10T12:37:14+00:00 URL: https://externals.io/message/93858#93859 · In reply to: #93858 Hi, I hardly worked on implementation of this patch for a week, but I still don't like it. It makes 15% slowdown on each property update in existing PHP code (without types), and I don't see a way to improve this. Update of typed properties is going to be even more expensive. Benchmark results are included into RFC (and not changed with the latest version of the patch). -1. Thanks. Dmitry. --- ## #93860 — Marco Pivetta — 2016-06-10T12:39:16+00:00 URL: https://externals.io/message/93858#93860 · In reply to: #93858 As already mentioned on twitter, I voted "no" on this RFC as it currently stands. I might reconsider if following points are addressed: 1. __get semantics are not changed: let __get behave like it usually does, and let the user define a type hint on __get, should any be applicable. Basically: class Foo { private int $bar = 123; public function __get($name) { return 'banana'; } // *ALWAYS* works - why would I even want a type error here? } * by-ref access should be enabled when the reference property has the same declared type as the source one class Foo { public int $bar = 123; } class Bar { public int $baz = 456; public string $taz = 'taz'; } $foo = new Foo; $bar = new Bar; $bar->baz = & $foo->bar; // works $bar->taz = & $foo->bar; // crashes Cheers, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ > Afternoon internals, > > The vote for typed properties has been restarted. > > Please take part: https://wiki.php.net/rfc/typed-properties > > Cheers > Joe --- ## #93861 — Niklas Keller — 2016-06-10T12:55:11+00:00 URL: https://externals.io/message/93858#93861 · In reply to: #93860 2016-06-10 14:39 GMT+02:00 Marco Pivetta : > As already mentioned on twitter, I voted "no" on this RFC as it currently > stands. I might reconsider if following points are addressed: > > 1. __get semantics are not changed: let __get behave like it usually does, > and let the user define a type hint on __get, should any be applicable. > Basically: > > class Foo > { > private int $bar = 123; > public function __get($name) { return 'banana'; } // *ALWAYS* works - > why would I even want a type error here? > } > You want a type error if bar is unset, mainly because Foo->bar should always be an int. If you unset it and set it again, it still has to be an int. And reflection will tell you it's always an int. So why should __get be allowed to return something different? > * by-ref access should be enabled when the reference property has the same > declared type as the source one > > class Foo > { > public int $bar = 123; > } > > class Bar > { > public int $baz = 456; > public string $taz = 'taz'; > } > > $foo = new Foo; > $bar = new Bar; > > $bar->baz = & $foo->bar; // works > $bar->taz = & $foo->bar; // crashes > > Cheers, > > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > > > > […] --- ## #93862 — Marco Pivetta — 2016-06-10T13:01:15+00:00 URL: https://externals.io/message/93858#93862 · In reply to: #93861 Top-posting, since I'm taking off now. From outside the class, properties are not visible at all, so their types are un-important from outer scopes. echo $foo->bar; is not the same in instance method body or outside of the class. > 2016-06-10 14:39 GMT+02:00 Marco Pivetta : > > > […] > > You want a type error if bar is unset, mainly because Foo->bar should > always be an int. > If you unset it and set it again, it still has to be an int. And > reflection will tell you it's always an int. > So why should __get be allowed to return something different? > > > > […] --- ## #93863 — Niklas Keller — 2016-06-10T13:34:17+00:00 URL: https://externals.io/message/93858#93863 · In reply to: #93862 > > Top-posting, since I'm taking off now. > > From outside the class, properties are not visible at all, so their types > are un-important from outer scopes. > > echo $foo->bar; is not the same in instance method body or outside of the > class. > From outside it works just fine and doesn't throw: https://3v4l.org/L8CqF/rfc#rfc-typed_properties --- ## #93864 — Bob Weinand — 2016-06-10T13:50:06+00:00 URL: https://externals.io/message/93858#93864 · In reply to: #93863 > Am 10.6.2016 um 15:34 schrieb Niklas Keller : > > > […] > From outside it works just fine and doesn't throw: > https://3v4l.org/L8CqF/rfc#rfc-typed_properties This is an intermittent bug in the implementation. the RFC is explicitly mentioning that it should throw and throwing also is the correct behavior here. Bob --- ## #93865 — Niklas Keller — 2016-06-10T14:00:37+00:00 URL: https://externals.io/message/93858#93865 · In reply to: #93864 2016-06-10 15:50 GMT+02:00 Bob Weinand : > > Am 10.6.2016 um 15:34 schrieb Niklas Keller : > > > Top-posting, since I'm taking off now. > > From outside the class, properties are not visible at all, so their types > are un-important from outer scopes. > > echo $foo->bar; is not the same in instance method body or outside of the > class. > > From outside it works just fine and doesn't throw: > https://3v4l.org/L8CqF/rfc#rfc-typed_properties > > > This is an intermittent bug in the implementation. > the RFC is explicitly mentioning that it should throw and throwing also is > the correct behavior here. > I don't think this is and should be a bug. I think it is the right behavior if we choose to throw at all. --- ## #93866 — Bob Weinand — 2016-06-10T14:12:34+00:00 URL: https://externals.io/message/93858#93866 · In reply to: #93865 > Am 10.06.2016 um 16:00 schrieb Niklas Keller : > > 2016-06-10 15:50 GMT+02:00 Bob Weinand >: > > > […] > > This is an intermittent bug in the implementation. > the RFC is explicitly mentioning that it should throw and throwing also is the correct behavior here. > > I don't think this is and should be a bug. I think it is the right behavior if we choose to throw at all. In this case a definite -1 on the RFC from me. I don't want "surprises" regarding the type if a property is declared to return a certain type. Bob --- ## #93867 — Niklas Keller — 2016-06-10T14:16:09+00:00 URL: https://externals.io/message/93858#93867 · In reply to: #93866 2016-06-10 16:12 GMT+02:00 Bob Weinand : > In this case a definite -1 on the RFC from me. I don't want "surprises" > regarding the type if a property is declared to return a certain type. > Where's the surprise? --- ## #93868 — Bob Weinand — 2016-06-10T14:19:41+00:00 URL: https://externals.io/message/93858#93868 · In reply to: #93867 > Am 10.06.2016 um 16:16 schrieb Niklas Keller : > > > 2016-06-10 16:12 GMT+02:00 Bob Weinand >: > In this case a definite -1 on the RFC from me. I don't want "surprises" regarding the type if a property is declared to return a certain type. > > Where's the surprise? Receiving a different type than I asked for. (as promised by the type decl) Bob --- ## #93869 — Levi Morrison — 2016-06-10T14:24:48+00:00 URL: https://externals.io/message/93858#93869 · In reply to: #93859 > Hi, > > > I hardly worked on implementation of this patch for a week, but I still don't like it. > > It makes 15% slowdown on each property update in existing PHP code (without types), and I don't see a way to improve this. > > Update of typed properties is going to be even more expensive. > > Benchmark results are included into RFC (and not changed with the latest version of the patch). > > > -1. > > > Thanks. Dmitry. > > ________________________________ > From: Joe Watkins > Sent: Friday, June 10, 2016 1:38:04 PM > To: PHP internals; Phil Sturgeon > Subject: [PHP-DEV] [RFC][Vote] Typed Properties > > Afternoon internals, > > The vote for typed properties has been restarted. > > Please take part: https://wiki.php.net/rfc/typed-properties > > Cheers > Joe To clarify though, didn't Wordpress and Mediawiki see only a 0.1% slowdown? In my opinion that is definitely a tolerable performance hit for such a feature. --- ## #93870 — Bob Weinand — 2016-06-10T14:31:43+00:00 URL: https://externals.io/message/93858#93870 · In reply to: #93869 > Am 10.06.2016 um 16:24 schrieb Levi Morrison : > > > > […] > > To clarify though, didn't Wordpress and Mediawiki see only a 0.1% > slowdown? In my opinion that is definitely a tolerable performance hit > for such a feature. Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 cache utilization and the number of executed instructions for a runtime-cached ASSIGN_OBJ is very small. Where even 4 additional instructions make significant difference. The 0.1% slowdown of WP and MW are painting a much more realistic (aka real-world) image. And as the RFC writes, "may be caused not by the additional checks but by the worse CPU cache utilization, because the size of PHP code was increased on 40KB". These micro-benches are really insignificant, especially as it is trivial (in tight loops) to work on a local CV and only assign it later to the property. This IMO is really voting no for the wrong reasons... Bob --- ## #93871 — Joe Watkins — 2016-06-10T14:42:32+00:00 URL: https://externals.io/message/93858#93871 · In reply to: #93866 That's a bug ... that should throw ... Cheers Joe > > Am 10.06.2016 um 16:00 schrieb Niklas Keller : > > 2016-06-10 15:50 GMT+02:00 Bob Weinand : > > > […] > > I don't think this is and should be a bug. I think it is the right > behavior if we choose to throw at all. > > > In this case a definite -1 on the RFC from me. I don't want "surprises" > regarding the type if a property is declared to return a certain type. > > Bob --- ## #93873 — Joe Watkins — 2016-06-10T14:58:07+00:00 URL: https://externals.io/message/93858#93873 · In reply to: #93871 Woops, no it isn't ... the property is private ... Cheers Joe > That's a bug ... that should throw ... > > Cheers > Joe > > > > > […] --- ## #93874 — Dmitry Stogov — 2016-06-10T15:01:21+00:00 URL: https://externals.io/message/93858#93874 · In reply to: #93869 > > > […] > To clarify though, didn't Wordpress and Mediawiki see only a 0.1% > slowdown? In my opinion that is definitely a tolerable performance hit > for such a feature. I don't see any big value in this feature. Most framework access their properties through getters and setters anyway. They can be and should be used to provide type-safe API. Another level of protection that makes slowdown instead of expected speedup, doesn't make any sense for me. Thanks. Dmitry. --- ## #93875 — Dmitry Stogov — 2016-06-10T15:03:29+00:00 URL: https://externals.io/message/93858#93875 · In reply to: #93869 Hi, I hardly worked on implementation of this patch for a week, but I still don't like it. It makes 15% slowdown on each property update in existing PHP code (without types), and I don't see a way to improve this. Update of typed properties is going to be even more expensive. Benchmark results are included into RFC (and not changed with the latest version of the patch). -1. Thanks. Dmitry. --- ## #93877 — Dmitry Stogov — 2016-06-10T15:24:09+00:00 URL: https://externals.io/message/93858#93877 · In reply to: #93870 > > […] > Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 cache utilization and the number of executed instructions for a runtime-cached ASSIGN_OBJ is very small. Where even 4 additional instructions make significant difference. The current fast-path of ASSIGN_DIM is about 40 instruction, so 15% slowdown comes exactly from this additional 4 instructions and additional memory read. > The 0.1% slowdown of WP and MW are painting a much more realistic (aka real-world) image. And as the RFC writes, "may be caused not by the additional checks but by the worse CPU cache utilization, because the size of PHP code was increased on 40KB". Yes, this is my words :) > > These micro-benches are really insignificant, especially as it is trivial (in tight loops) to work on a local CV and only assign it later to the property. they show the effect of the patch on the affected operations, and the shown slowdown is significant. Of course this doesn't affect WP significantly, because the whole ASSIGN_OBJ cost in the app is less than 1%. So we slowdown this ~1% on ~15% and got ~0.1% cumulative slowdown. Thanks. Dmitry. > > This IMO is really voting no for the wrong reasons... > > Bob --- ## #93878 — Larry Garfield — 2016-06-10T16:16:46+00:00 URL: https://externals.io/message/93858#93878 · In reply to: #93874 > > > […] > I don't see any big value in this feature. > Most framework access their properties through getters and setters > anyway. > They can be and should be used to provide type-safe API. > Another level of protection that makes slowdown instead of expected > speedup, doesn't make any sense for me. > > Thanks. Dmitry. Needing an explicit getter and setter (and the overhead of the function call) just for type checking is a bug this feature would obviate. If the only value of the getter/setter is type safety, then you're better off not using them. (There are other reasons to have getters and setters, and I'd still love to see the property accessor RFC reborn, but that's a separate issue.) Additionally, typed properties provides a terser, more self-documenting way of communicating the property type and thus expected behavior. I've written several doctrine classes, for instance, that are 5 lines of properties and 30 lines of getters/setters/docs boilerplate. If that boilerplate can be reduced or eliminated, that's a win. It also provides better introspection capabilities for ORMs and similar serialization tools. Yes, in some cases richer data than this RFC provides is helpful but not always. In many cases this would be sufficient to build automated safety into automated tools. (ORMs, serializers, validators that now don't need to be written at all, etc.) That seems like a worthwhile trade-off for a <1% performance difference in a real-world application. --Larry Garfield --- ## #93879 — Rowan Collins — 2016-06-10T16:57:04+00:00 URL: https://externals.io/message/93858#93879 · In reply to: #93878 > That seems like a worthwhile trade-off for a <1% performance difference > in a real-world application. The problem is that the performance hit is felt even for code that doesn't "opt in" to this feature. For an application that makes no use of the feature, it is all cost and no benefit. I think PHP is at a cross-roads, and (if you'll forgive the stretched analogy) at risk of going off-road and getting stuck in the mud. Option 1 is that the language remains inherently loose-typed, with a few entirely optional features to provide type safety in specific cases. If this is the aim, then the optional features should be as unobtrusive as possible for the "default" loose-typed approach. Any performance hit on untyped properties is a big deal under this interpretation. Option 2 is that the language embraces "gradual typing" as a core tenet of the language, with loose typing considered a "fallback". If this is the aim, then there should be a coherent roadmap of what the type system is going to look like. In this case, performance issues might be considered an inevitable cost of improving the language; they might also be reduced as the Engine is adapted to implement the roadmap. Option 1 seems more appealing, because it is easier to get agreement for, but if we keep piling on the special cases, we're going to end up with the worst of both worlds. I see the technical problems with creating a reference to a typed property as a sign of this: we are creating more of the frustrating inconsistencies that PHP is infamous for, because we're trying to have our cake and eat it. For the record, I'm not entirely sure which way I want the language to go, but I think it's a decision that needs to be made, and soon. Regards, -- Rowan Collins [IMSoP] --- ## #93880 — Larry Garfield — 2016-06-10T17:28:47+00:00 URL: https://externals.io/message/93858#93880 · In reply to: #93879 > > > […] > > The problem is that the performance hit is felt even for code that > doesn't "opt in" to this feature. For an application that makes no use > of the feature, it is all cost and no benefit. > > I think PHP is at a cross-roads, and (if you'll forgive the stretched > analogy) at risk of going off-road and getting stuck in the mud. > > Option 1 is that the language remains inherently loose-typed, with a > few entirely optional features to provide type safety in specific > cases. If this is the aim, then the optional features should be as > unobtrusive as possible for the "default" loose-typed approach. Any > performance hit on untyped properties is a big deal under this > interpretation. > > Option 2 is that the language embraces "gradual typing" as a core > tenet of the language, with loose typing considered a "fallback". If > this is the aim, then there should be a coherent roadmap of what the > type system is going to look like. In this case, performance issues > might be considered an inevitable cost of improving the language; they > might also be reduced as the Engine is adapted to implement the roadmap. > > Option 1 seems more appealing, because it is easier to get agreement > for, but if we keep piling on the special cases, we're going to end up > with the worst of both worlds. I see the technical problems with > creating a reference to a typed property as a sign of this: we are > creating more of the frustrating inconsistencies that PHP is infamous > for, because we're trying to have our cake and eat it. > > For the record, I'm not entirely sure which way I want the language to > go, but I think it's a decision that needs to be made, and soon. > > Regards, This is a very accurate and well-stated assessment. I agree with the possible paths. From the code I see in the wild, it feels like the gradually/mostly typed camp has already won in terms of production code. Most of the PHP Rennaissance-era systems (the stuff that came out in the last 5-6 years or so) is class-heavy and as type safe as PHP has allowed, most of the time. The exceptions are the highly functional bits, where the language doesn't offer as much support as it does for class-family typing. There's almost certainly some projecting going on here as I'm a mostly-typed fan myself, but my sense is that the PHP user-space community has already decided they want a robust typing system they can use in most (but not all) cases. The engine should embrace that and catch up, with a well thought-out approach to typing. If it takes a bit longer to get certain features as a result of that attention to a coherent roadmap, I am happy to make that trade-off. --Larry Garfield --- ## #93882 — Lester Caine — 2016-06-10T19:14:42+00:00 URL: https://externals.io/message/93858#93882 · In reply to: #93879 > > For the record, I'm not entirely sure which way I want the language to > go, but I think it's a decision that needs to be made, and soon. Seconded ... even something like strict mode should be 'removable' to provide a smaller faster 'classic' PHP even if it does mean there are two builds. But we already HAVE two builds ... people who want strongly typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP down the same road map? Each has it's own strengths. -- 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 --- ## #93883 — Larry Garfield — 2016-06-10T19:51:12+00:00 URL: https://externals.io/message/93858#93883 · In reply to: #93882 > > > […] > Seconded ... even something like strict mode should be 'removable' to > provide a smaller faster 'classic' PHP even if it does mean there are > two builds. But we already HAVE two builds ... people who want strongly > typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP > down the same road map? Each has it's own strengths. ... I am a strong typing proponent (that is a strong proponent of explicit typing), and have never once used HHVM. Your claim, that type-using people can just leave for HHVM, is both nonsensical and untrue. --Larry Garfield --- ## #93884 — Lester Caine — 2016-06-10T20:01:28+00:00 URL: https://externals.io/message/93858#93884 · In reply to: #93883 > > > […] > > ... I am a strong typing proponent (that is a strong proponent of > explicit typing), and have never once used HHVM. Your claim, that > type-using people can just leave for HHVM, is both nonsensical and untrue. The same applies to your suggestion that user-land is actively following you. Getting systems off PHP5.2/3 gets more an more difficult given all the extra 'little tweaks' that are needed and we still have 40% of users that need help getting just over to 5.4 let alone up to PHP7. Currently more people are still using PHP4 than have switched to PHP7 ... so where is the strong support for typed code? (https://w3techs.com/technologies/details/pl-php/all/all) -- 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 --- ## #93888 — Larry Garfield — 2016-06-10T21:05:38+00:00 URL: https://externals.io/message/93858#93888 · In reply to: #93884 > > > […] > The same applies to your suggestion that user-land is actively following > you. Getting systems off PHP5.2/3 gets more an more difficult given all > the extra 'little tweaks' that are needed and we still have 40% of users > that need help getting just over to 5.4 let alone up to PHP7. Currently > more people are still using PHP4 than have switched to PHP7 ... so where > is the strong support for typed code? > > (https://w3techs.com/technologies/details/pl-php/all/all) https://seld.be/notes/php-versions-stats-2016-1-edition The code being written is veering heavily toward newer versions, and anecdotally most of the code I see is classed with typed parameters. (Yes, anecdotes are not data, and I acknowledged a likely bias earlier, but I'm not sure how to generate actually objective data on this front.) That is arguably a more reliable measure of what developers are doing than the W3Techs stats, which are based on what servers are running. (A useful but different metric.) --Larry Garfield --- Next page: https://externals.io/message/93858.md?page=2