Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][Vote] Typed Properties »

[RFC][Vote] Typed Properties

php.internals

Joe Watkins

10 years ago
Afternoon internals, The vote for typed properties has been restarted. Please take part: https://wiki.php.net/rfc/typed-properties Cheers Joe

Dmitry Stogov

10 years ago
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 <pthreads@pthreads.org> 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

Levi Morrison

10 years ago
On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> 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 <pthreads@pthreads.org> > 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.

Bob Weinand

10 years ago
> Am 10.06.2016 um 16:24 schrieb Levi Morrison <levim@php.net>: > > On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmitry@zend.com> wrote: >> 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 <pthreads@pthreads.org> >> 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.
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

Dmitry Stogov

10 years ago
On 06/10/2016 05:31 PM, Bob Weinand wrote:
>> Am 10.06.2016 um 16:24 schrieb Levi Morrison <levim@php.net>: >> >> On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmitry@zend.com> wrote: >>> 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 <pthreads@pthreads.org> >>> 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. > 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.

Dmitry Stogov

10 years ago
On 06/10/2016 05:24 PM, Levi Morrison wrote:
> On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmitry@zend.com> wrote: >> 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 <pthreads@pthreads.org> >> 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.
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.

Larry Garfield

10 years ago
On 06/10/2016 10:01 AM, Dmitry Stogov wrote:
> >> 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.
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

Rowan Collins

10 years ago
On 10/06/2016 17:16, Larry Garfield wrote:
> 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]

Larry Garfield

10 years ago
On 06/10/2016 11:57 AM, Rowan Collins wrote:
> On 10/06/2016 17:16, Larry Garfield wrote: >> 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,
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

Lester Caine

10 years ago
On 10/06/16 17:57, Rowan Collins wrote:
> > 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

Larry Garfield

10 years ago
On 06/10/2016 02:14 PM, Lester Caine wrote:
> On 10/06/16 17:57, Rowan Collins wrote: >> 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.
... 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

Lester Caine

10 years ago
On 10/06/16 20:51, Larry Garfield wrote:
> On 06/10/2016 02:14 PM, Lester Caine wrote: >> On 10/06/16 17:57, Rowan Collins wrote: >>> 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. > > ... 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

Larry Garfield

10 years ago
On 06/10/2016 03:01 PM, Lester Caine wrote:
> On 10/06/16 20:51, Larry Garfield wrote: >> On 06/10/2016 02:14 PM, Lester Caine wrote: >>> On 10/06/16 17:57, Rowan Collins wrote: >>>> 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. >> ... 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)
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

Dmitry Stogov

10 years ago
On 06/10/2016 05:24 PM, Levi Morrison wrote: On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov <dmitry@zend.com><mailto:dmitry@zend.com> wrote: 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 <pthreads@pthreads.org><mailto:pthreads@pthreads.org> 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. I don't see any big value in this feature. Most framework access object 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, dosn't make any sense. Thanks. Dmitry.

Yasuo Ohgaki

10 years ago
Hi Dmitry, On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> 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.
If we are concerned about performance, DbC would be the only solution for this kind of problem. i.e. Validate fully during development, do minimum validation on production. DbC helps type inference also. There may not be enough time for discussion, but do you think there is enough time for implementation? I suppose implementation is straightforward, so it might be OK to have RFC w/o implementation. We have 2 options anyway. It's waste of time for having 2 implementations. Would you like to proceed the RFC for 7.1? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Rasmus Schultz

10 years ago
Pretend I know (basically) nothing about how PHP was implemented, because I don't ;-) But I don't understand why regular property updates should be affected by this at all? If I had to implement type-checked properties in plain PHP, I would do something like this... /** * @property int $price */ class Product { private $_price; public function __set($name, $value) { if ($name === "price") { if (!is_int($value)) { throw new UnexpectedValueException("..."); } $this->_price = $price; return; } throw new RuntimeException("undefined property {$name}"); } public function __get($name) { return $this->{"_{$name}"}; } } I would have guessed an implementation of type-checked properties would work in much the same way. Of course, it wouldn't use "_" as a prefix for the underlying property, but some other magic byte, much like how private properties are internally prefixed with a magic byte, right? This wouldn't affect the performance of untyped properties at all. Of course typed property writes would be more expensive, but that's to be expected. On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

Lester Caine

10 years ago
On 12/06/16 14:03, Rasmus Schultz wrote:
> If I had to implement type-checked properties in plain PHP, I would do > something like this... > > /** > * @property int $price > */ > class Product > { > private $_price; > > public function __set($name, $value) { > if ($name === "price") { > if (!is_int($value)) { > throw new UnexpectedValueException("..."); > } > $this->_price = $price;
$this->_price = $value;
> return; > } > throw new RuntimeException("undefined property {$name}"); > } > > public function __get($name) { > return $this->{"_{$name}"}; > } > }
I'm with you on not totally understanding the internals, but ... var $_price; Added code to handle the access restrictions, so checks have to be made on just how $this->_price is accessed. In my book, the __set function validates range as well as checking so value is of the right type and any range error can be handled at the right point. However if you add 'int' to the private then this now adds a check to see if there IS a type restriction on the 'var' in addition to access restriction. Checks for 'strict' come in here as well? But I still see a lot more cases where the 'is_int' checks are needed in the normal flow prior to any ACTUAL assignment to the typed property. SO it makes a lot more sense to me that '$this->_price = $value;' either does the job of validation fully, or does not do it at all? And there should be no distinction between $this->_price = $value; and $this->params_array[_price] = $value; It is exactly the same variable?
-- 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

Joe Watkins

10 years ago
Morning,
> This wouldn't affect the performance of untyped properties at all.
There are extra instructions in that code. When the code you have is only 5 instructions, adding 1 more instruction makes a 20% increase in instructions ... That is what we are looking at in these micro benchmarks; The number of instructions is so small, that even the small difference is measurable. Of course you can measure the difference, and obviously there are going to be more instructions, but we should only care about what effects real world code. This doesn't effect real world code. Cheers Joe On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:

Michał Brzuchalski

10 years ago
Hi, I may don't have voting privileges but as an 10yr PHP development practitioner I can't believe that such big and awesome feature like Typed Properties minimally can't have enought votes to be a part of PHP language (26/(26+16) = 62% and that's not enoght to 2/3+1vote). There are plenty of places where type hinting actually exists and looks like Typed Properties can be great complement of type system in PHP language with the ability to still be so dynamic language as it is right now. The impact of 0.1% (or even more) of performance IMHO should not have no significant meaning. Someone earlier wrote that properties types should be ensured by frameworks - but that doesn't never happen, the impact on performance while dynamically type checking inside setters would be few times greates than this patch impact. Not to mention the fact that the feature itself suggests good practice. Without it, we will still have setters/getters hell, and there will newer be safe frameworks instad there will always be some hack's inside subclasses or some other ways. Without it, PHP will newer be aqualed such as Java, C# even Hack language - there still will continue to be a big gap, due to the lack of type hinting. Sure you could say start to code in Hack it has type safier system, it has generics, annotations and other features which from time to time are in PHP RFC's but most of time they are declined and Hack lacks of great IDE support like PHPStorm which I use and love because of refactor, code styling, run&debug etc. PHP language has poor type safety and IMHO without such patches it will never evolve into type safety programming language. Regards,
-- Michał Brzuchalski 2016-06-13 11:40 GMT+02:00 Joe Watkins <pthreads@pthreads.org>: > Morning, > > > This wouldn't affect the performance of untyped properties at all. > > There are extra instructions in that code. > > When the code you have is only 5 instructions, adding 1 more instruction > makes a 20% increase in instructions ... > > That is what we are looking at in these micro benchmarks; The number of > instructions is so small, that even the small difference is measurable. > > Of course you can measure the difference, and obviously there are going to > be more instructions, but we should only care about what effects real world > code. > > This doesn't effect real world code. > > Cheers > Joe > > On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz <rasmus@mindplay.dk> > wrote: > > > Pretend I know (basically) nothing about how PHP was implemented, because > > I don't ;-) > > > > But I don't understand why regular property updates should be affected by > > this at all? > > > > If I had to implement type-checked properties in plain PHP, I would do > > something like this... > > > > /** > > * @property int $price > > */ > > class Product > > { > > private $_price; > > > > public function __set($name, $value) { > > if ($name === "price") { > > if (!is_int($value)) { > > throw new UnexpectedValueException("..."); > > } > > $this->_price = $price; > > return; > > } > > throw new RuntimeException("undefined property {$name}"); > > } > > > > public function __get($name) { > > return $this->{"_{$name}"}; > > } > > } > > > > I would have guessed an implementation of type-checked properties would > > work in much the same way. > > > > Of course, it wouldn't use "_" as a prefix for the underlying property, > > but some other magic byte, much like how private properties are > internally > > prefixed with a magic byte, right? > > > > This wouldn't affect the performance of untyped properties at all. > > > > Of course typed property writes would be more expensive, but that's to be > > expected. > > > > > > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> > wrote: > > > >> Hi Dmitry, > >> > >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov <dmitry@zend.com> wrote: > >> > 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. > >> > >> If we are concerned about performance, DbC would be the only solution > >> for this kind of problem. i.e. Validate fully during development, do > >> minimum validation on production. DbC helps type inference also. There > >> may not be enough time for discussion, but do you think there is > >> enough time for implementation? I suppose implementation is > >> straightforward, so it might be OK to have RFC w/o implementation. We > >> have 2 options anyway. It's waste of time for having 2 > >> implementations. Would you like to proceed the RFC for 7.1? > >> > >> Regards, > >> > >> -- > >> Yasuo Ohgaki > >> yohgaki@ohgaki.net > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > >> > > > -- pozdrawiam -- Michał Brzuchalski

Lester Caine

10 years ago
On 22/06/16 10:37, Michał Brzuchalski wrote:
> Without it, PHP will newer be aqualed such as Java, C# even Hack language - > there still will continue to be a big gap, due to the lack of type hinting. > Sure you could say start to code in Hack it has type safier system, it has > generics, annotations and other features which from time to time are in PHP > RFC's but most of time they are declined and Hack lacks of great IDE > support like PHPStorm which I use and love because of refactor, code > styling, run&debug etc.
If all these other languages are so much better why is the usage of PHP *SO* much greater than any of them with no sign of any of them gaining traction? Simply because for the vast number of users the simplicity of PHP works ... they are not degree level software engineers.
-- 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

Michał Brzuchalski

10 years ago
Hi, I agree with you, but this patch does not result in any increase in complexity - there still will be a way to declare non typed properties and most of those developers wouldn't even fell any impact complexity on development stage. My goal is not to judge which language is better but to visualize loss for the mass of developers will be the rejection of that patch. Nobody will pursuade me not that type safety is nothing significant in programming language. According to "they are not degree level software engineers" I must dissagree with you - they are less payed (their salary is 11%-15% less than other mentioned language developers) also there is less great and huge working projects/applications in the real life, most of engineering colleges learn those other mentioned languages not PHP and there is also never ending sneering war beetween PHP developers and those other mentioned. Regards,
-- Michał Brzuchalski 2016-06-22 11:59 GMT+02:00 Lester Caine <lester@lsces.co.uk>: > On 22/06/16 10:37, Michał Brzuchalski wrote: > > Without it, PHP will newer be aqualed such as Java, C# even Hack > language - > > there still will continue to be a big gap, due to the lack of type > hinting. > > Sure you could say start to code in Hack it has type safier system, it > has > > generics, annotations and other features which from time to time are in > PHP > > RFC's but most of time they are declined and Hack lacks of great IDE > > support like PHPStorm which I use and love because of refactor, code > > styling, run&debug etc. > > If all these other languages are so much better why is the usage of PHP > *SO* much greater than any of them with no sign of any of them gaining > traction? Simply because for the vast number of users the simplicity of > PHP works ... they are not degree level software engineers. > > -- > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- pozdrawiam -- Michał Brzuchalski

Lester Caine

10 years ago
On 22/06/16 11:25, Michał Brzuchalski wrote:
> Nobody will pursuade me not that type safety is nothing significant in > programming language.
'type safety' is perhaps the problem here. In a compiled language you are only ever passing a binary value for which the 'type' is a critical element, but move away from the straight jacket of binary variables and allow a user to type a number into a box and use that string value as a variable then the 'type safety' needs to be implemented at the entry point ... including checking the range of the number ... and so there is no point adding code to every usage of a variable that has correctly been validated already. Variables already stored will already have been validated so again the 'additional' check that an integer is an integer has little value? Now start from a situation where we have a proper typed 'var' with the ability to set constraints such as range or string length, then attempts to store the wrong value can be handled ... something that several user coded frameworks already provide ... then even the 'strict' debate has a completely different base?
-- 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

Rasmus Schultz

10 years ago
On Wed, Jun 22, 2016 at 11:59 AM, Lester Caine <lester@lsces.co.uk> wrote:
> > If all these other languages are so much better why is the usage of PHP > *SO* much greater than any of them with no sign of any of them gaining > traction?
I'm sorry, but that kind of rhetoric is really unproductive. At no point did anyone suggest that type-checked properties was the *only* difference between languages that matter - that would be absurd. All anyone is suggesting, is that it *does* matter - to argue that it doesn't, solely based on what people are choosing, is silly. There are many factors of choice. I (along with most of my co-workers) yearn for a language-level replacement for the ugly, unsafe, verbose php-doc tags everyone needs to scatter around right now to get proper inspections about property-types etc. - that yearning isn't driving me to another language, because there are many other aspects to the language that I enjoy, but it does remain on my top-10 list of the most desperately missing features in PHP. Having worked in other gradually-typed languages like Dart and Typescript, PHP feels crippled on this point - it's gradually-typed, but inconsistently so, and inconsistency is the worst kind of evil you can have in any programming language. New PHP developer: - great, I can declare types like classes and interfaces! - great, I can type-hint parameters! - great, I can type-hint return-types! - oh wait, how do I type-hint my properties...? - oh. I can't. - oh, there's tools for that. - oh, tools only do half the job... The learning curve for new users isn't increased by the introduction of property type-hints, it's *decreased* - they have to learn about types to write classes and interfaces, they have to learn about type-hints when it comes to functions, but then, in addition, they have to learn about the things they *can't* type-hint, for some reason, not that anybody is offering an explanation, it's just a matter of fact, and then in addition they need to go and learn about php-doc and offline inspection tools and IDEs and so forth. And a lot of developers are going to give up and resign themselves to doing just what the language offers, long before learning all of that, which could take them years, and in the mean time they write and publish "newbie-looking" code, giving PHP developers a bad rep, lower salaries, etc. - but it's not their fault, as most of them have a boss asking them to produce code, now, and learning how to work around the language to write good code takes a long time and a lot of effort for most people. Meanwhile, skilled developers who went the extra mile are out there complaining about these missing features in PHP. Give them a consistent language and new developers will rise to the occasion - I'm sure of it. You're just not giving them a chance. Type-hinted properties are a step towards fixing that situation - they don't add, they *remove* complexity and learning curve from the language. Consistency, when it comes to languages, is always simpler and less surprising than inconsistency. PHP *has* type-checks - the introduction of property type-hints is not a new feature, it's fixing an inconsistency. Sorry, for the rant, but anti-type-hints is just anti-consistency. We have type-hints, now let's please take another step towards finishing the job!

Christoph Becker

10 years ago
On 22.06.2016 at 17:58, Rasmus Schultz wrote:
> Give them a consistent language and new developers will rise to the > occasion - I'm sure of it. You're just not giving them a chance. > Type-hinted properties are a step towards fixing that situation - they > don't add, they *remove* complexity and learning curve from the > language. > > Consistency, when it comes to languages, is always simpler and less > surprising than inconsistency.
ACK.
> PHP *has* type-checks - the introduction of property type-hints is not > a new feature, it's fixing an inconsistency.
I'd argue that the current proposal brings new inconsistencies, namely that you can type properties (besides already supported parameters), but not other variables (okay, these are not properties, but still), no static properties and there are restrictions regarding references to typed properties. In my opinion, these restrictions can be very confusing for users – one already sufficient reason for me to abstain from voting on a feature I'd like in principle.
-- Christoph M. Becker

Larry Garfield

10 years ago
On 06/22/2016 10:58 AM, Rasmus Schultz wrote:
> The learning curve for new users isn't increased by the introduction > of property type-hints, it's *decreased*
I want to put that line on a plaque. It applies for a lot of features being offered for PHP: They do actually make the language easier, not harder, by making the baseline language more consistent, robust, and coherent. The same argument can, and likely will, be made for native async; sure it *can* be done in userspace, but doing it in a standard way in the language will make it *easer*, not harder, to use PHP to its full potential. No, this is not true of every new language feature, but it is true of many of them. The language needs to serve the ecosystem, not vice versa. --Larry Garfield

Michał Brzuchalski

10 years ago
2016-06-22 18:49 GMT+02:00 Larry Garfield <larry@garfieldtech.com>:
> On 06/22/2016 10:58 AM, Rasmus Schultz wrote: > >> The learning curve for new users isn't increased by the introduction >> of property type-hints, it's *decreased* >> > > I want to put that line on a plaque. It applies for a lot of features > being offered for PHP: They do actually make the language easier, not > harder, by making the baseline language more consistent, robust, and > coherent. > > The same argument can, and likely will, be made for native async; sure it > *can* be done in userspace, but doing it in a standard way in the language > will make it *easer*, not harder, to use PHP to its full potential. > > No, this is not true of every new language feature, but it is true of many > of them. The language needs to serve the ecosystem, not vice versa. > > --Larry Garfield > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
I fully agree with Rasmus, I'm kind of developer complaining about the missing PHP features. At the same time often teach new programmers see their surprise and embarrassment with lack of this functionality.
-- pozdrawiam -- Michał Brzuchalski

Rowan Collins

10 years ago
On 22/06/2016 16:58, Rasmus Schultz wrote:
> On Wed, Jun 22, 2016 at 11:59 AM, Lester Caine <lester@lsces.co.uk> wrote: > Having worked in other gradually-typed languages like Dart and > Typescript
Out of curiosity, do these languages perform the type analysis at compilation, or at run-time? I'm trying to collate some examples of how other languages have approached the problem.
> PHP feels crippled on this point - it's gradually-typed, > but inconsistently so, and inconsistency is the worst kind of evil you > can have in any programming language.
I absolutely agree, we need a plan for how to introduce a consistent gradual typing system. But this RFC is not that plan.
> The learning curve for new users isn't increased by the introduction > of property type-hints, it's *decreased*
Except that this proposal doesn't actually make the language consistently type-checked. It adds a few more special cases where you can use type hints, with slightly different behaviour. To carry on your imagined conversation: - ooh, I can type-hint properties now! - wait, what does this error mean? why would I not be able to assign this property by reference? - oh, because the variable holding the reference would have to be type-hinted; how do I do that? - oh, I can't...
> and then in addition they need to go and learn about > php-doc and offline inspection tools and IDEs and so forth.
Interestingly, this is the direction that Hack and Python have both apparently chosen to enshrine - the syntax is baked into the language, but not actually enforced by the standard compiler or run-time in any way. Indeed, "gradual typing" as defined by Jeremy Siek only really makes sense in the context of static analysis.
> Sorry, for the rant, but anti-type-hints is just anti-consistency. We > have type-hints, now let's please take another step towards finishing > the job!
Taking lots of little steps "towards" a goal that we've never even properly defined is exactly what leads to *inconsistency* in the language. I think a number of people are not "anti-type-hints", they just don't agree with this particular implementation. Regards,
-- Rowan Collins [IMSoP]

Rasmus Schultz

10 years ago
On Wed, Jun 22, 2016 at 7:44 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> > Out of curiosity, do these languages perform the type analysis at > compilation, or at run-time? I'm trying to collate some examples of how > other languages have approached the problem.
In Typescript, the type-hints are evaluated at compile-time only - there is no run-time footprint at all, which is why they're actually called "type annotations" in Typescript; they're just annotations serving as directives for the compiler. With Dart, you have a choice - you can actually toggle whether or no type-checks should be performed at run-time. It's probably the best of those two references, if you're looking for inspiration for PHP. In PHP, every type-check is performed at run-time, and type-hints are reflected - that's extremely important, and something Hack got horribly wrong, as the type-hints they introduced are merely annotations, with no run-time footprint, checked only by a static analyzer that runs in the background; completely inconsistent with type-checks in PHP.
>> PHP feels crippled on this point - it's gradually-typed, >> but inconsistently so, and inconsistency is the worst kind of evil you >> can have in any programming language. > > I absolutely agree, we need a plan for how to introduce a consistent gradual > typing system. But this RFC is not that plan.
Maybe it's imperfect in it's current state, but it sounds to me like it's pretty close? The only serious issue I've had to point at, is the inconsistency regarding references - but honestly, there are very (very) few reasons to use references in the first place; there is usually a much better solution with much less "wtf". (if I had to choose, honestly, I'd say deprecate references.)
>> The learning curve for new users isn't increased by the introduction > > Except that this proposal doesn't actually make the language consistently > type-checked. It adds a few more special cases where you can use type hints, > with slightly different behaviour.
That's not quite true. With the addition of property type-hints, the public surface through which you interact with objects would consistently support type-hints - so at least that makes object interactions and class design a lot more predictable. Yes, references are problem. Yes, type-hinted variables are a problem. But at least we're finally there as far as objects, which in PHP is probably the most important thing, as that's almost exclusively the means by which we share code.
>> and then in addition they need to go and learn about >> php-doc and offline inspection tools and IDEs and so forth. > > Interestingly, this is the direction that Hack and Python have both > apparently chosen to enshrine - the syntax is baked into the language, but > not actually enforced by the standard compiler or run-time in any way. > Indeed, "gradual typing" as defined by Jeremy Siek only really makes sense > in the context of static analysis.
Quoting Jeremy Siek: "Gradual typing allows software developers to choose either type paradigm as appropriate, from within a single language" - to me, that's the important thing about gradually-typed languages. Having worked with both Typescript and Dart, I can honestly say that I never missed run-time type-checks in Typescript, but on the other hand, I loved having reflection in Dart - I think it's not terribly important which approach a language takes, as long as it's consistent. PHP being a reflected and run-time type-checked language already, there is not much of a choice here; especially being a reflected language, having type-features that are available only in the context of static analysis, such as in Hack, would be highly problematic. I worked with Hack, briefly, and returned to PHP, one of the reasons being, things like generics and property type-hints did not support reflection, which meant that e.g. a reflection-based dependency injection container cannot grow to support and exploit those aspects of the language, which demonstrates why it's so important to be consistent: in Typescript, I would not have started writing a reflection-based DI container, because the language is not reflected, but in Hack, being a continuation of PHP, I would have naturally expected to continue in that direction.
> Taking lots of little steps "towards" a goal that we've never even properly > defined is exactly what leads to *inconsistency* in the language.
I don't disagree with that, and I think that's a large part of PHP's problems. But, on the other hand, we started down the road to gradual typing when we started adding type-hints - whether we knew what we were doing at the time or not, the next logical step down that road is property type-hints, which will at least clear up the number one biggest inconsistency as far as object and class design goes.
> I think a number of people are not "anti-type-hints", they just don't agree > with this particular implementation.
Very possible, and they may be right - but I really hope these people are doing something to help solve the problem, rather than simply killing the idea and offering no alternative.

Marco Pivetta

10 years ago
Top-posting due to mobile conn. I voted no due to flaws introduced in the language by the current RFC. The performance impact is irrelevant. On Jun 22, 2016 11:38, "Michał Brzuchalski" <michal@brzuchalski.com> wrote:

Michał Brzuchalski

10 years ago
Hi, According to my knowledge this path doesn't implement only string and int types but whole of type hinting. So your example usage of string and int maybe is unneded 'additional' check, but in other cases where you expect objects which implements specific inteface or class it's huge advantage when on runtime PHP checks if specific property is set properly - has proper type. Proper typed 'var' sure could be implemented in userland by complex type checks in setters, but do we really need that setters/getters hell with lots of `is_a`, `instanceof`, `class_implements` checks? There's something I now for sure, observed this on voting for RFC's from some time - if this path will be voted no there won't be any RFC with same functionality in near future. IMHO people writing RFC's and implementing patches they will not wanted to provide another RFC's and another implementation. Regards,
-- Michał Brzuchalski 2016-06-22 15:06 GMT+02:00 Marco Pivetta <ocramius@gmail.com>: > Top-posting due to mobile conn. > > I voted no due to flaws introduced in the language by the current RFC. > > The performance impact is irrelevant. > On Jun 22, 2016 11:38, "Michał Brzuchalski" <michal@brzuchalski.com> > wrote: > >> Hi, >> >> I may don't have voting privileges but as an 10yr PHP development >> practitioner I can't believe that such big and awesome feature like Typed >> Properties minimally can't have enought votes to be a part of PHP language >> (26/(26+16) = 62% and that's not enoght to 2/3+1vote). >> There are plenty of places where type hinting actually exists and looks >> like Typed Properties can be great complement of type system in PHP >> language with the ability to still be so dynamic language as it is right >> now. >> The impact of 0.1% (or even more) of performance IMHO should not have no >> significant meaning. >> Someone earlier wrote that properties types should be ensured by >> frameworks >> - but that doesn't never happen, the impact on performance while >> dynamically type checking inside setters would be few times greates than >> this patch impact. Not to mention the fact that the feature itself >> suggests >> good practice. >> Without it, we will still have setters/getters hell, and there will newer >> be safe frameworks instad there will always be some hack's inside >> subclasses or some other ways. >> Without it, PHP will newer be aqualed such as Java, C# even Hack language >> - >> there still will continue to be a big gap, due to the lack of type >> hinting. >> Sure you could say start to code in Hack it has type safier system, it has >> generics, annotations and other features which from time to time are in >> PHP >> RFC's but most of time they are declined and Hack lacks of great IDE >> support like PHPStorm which I use and love because of refactor, code >> styling, run&debug etc. >> PHP language has poor type safety and IMHO without such patches it will >> never evolve into type safety programming language. >> >> Regards, >> -- >> Michał Brzuchalski >> >> 2016-06-13 11:40 GMT+02:00 Joe Watkins <pthreads@pthreads.org>: >> >> > Morning, >> > >> > > This wouldn't affect the performance of untyped properties at all. >> > >> > There are extra instructions in that code. >> > >> > When the code you have is only 5 instructions, adding 1 more instruction >> > makes a 20% increase in instructions ... >> > >> > That is what we are looking at in these micro benchmarks; The number of >> > instructions is so small, that even the small difference is measurable. >> > >> > Of course you can measure the difference, and obviously there are going >> to >> > be more instructions, but we should only care about what effects real >> world >> > code. >> > >> > This doesn't effect real world code. >> > >> > Cheers >> > Joe >> > >> > On Sun, Jun 12, 2016 at 2:03 PM, Rasmus Schultz <rasmus@mindplay.dk> >> > wrote: >> > >> > > Pretend I know (basically) nothing about how PHP was implemented, >> because >> > > I don't ;-) >> > > >> > > But I don't understand why regular property updates should be >> affected by >> > > this at all? >> > > >> > > If I had to implement type-checked properties in plain PHP, I would do >> > > something like this... >> > > >> > > /** >> > > * @property int $price >> > > */ >> > > class Product >> > > { >> > > private $_price; >> > > >> > > public function __set($name, $value) { >> > > if ($name === "price") { >> > > if (!is_int($value)) { >> > > throw new UnexpectedValueException("..."); >> > > } >> > > $this->_price = $price; >> > > return; >> > > } >> > > throw new RuntimeException("undefined property {$name}"); >> > > } >> > > >> > > public function __get($name) { >> > > return $this->{"_{$name}"}; >> > > } >> > > } >> > > >> > > I would have guessed an implementation of type-checked properties >> would >> > > work in much the same way. >> > > >> > > Of course, it wouldn't use "_" as a prefix for the underlying >> property, >> > > but some other magic byte, much like how private properties are >> > internally >> > > prefixed with a magic byte, right? >> > > >> > > This wouldn't affect the performance of untyped properties at all. >> > > >> > > Of course typed property writes would be more expensive, but that's >> to be >> > > expected. >> > > >> > > >> > > On Sat, Jun 11, 2016 at 3:45 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> >> > wrote: >> > > >> > >> Hi Dmitry, >> > >> >> > >> On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov <dmitry@zend.com> >> wrote: >> > >> > 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. >> > >> >> > >> If we are concerned about performance, DbC would be the only solution >> > >> for this kind of problem. i.e. Validate fully during development, do >> > >> minimum validation on production. DbC helps type inference also. >> There >> > >> may not be enough time for discussion, but do you think there is >> > >> enough time for implementation? I suppose implementation is >> > >> straightforward, so it might be OK to have RFC w/o implementation. We >> > >> have 2 options anyway. It's waste of time for having 2 >> > >> implementations. Would you like to proceed the RFC for 7.1? >> > >> >> > >> Regards, >> > >> >> > >> -- >> > >> Yasuo Ohgaki >> > >> yohgaki@ohgaki.net >> > >> >> > >> -- >> > >> PHP Internals - PHP Runtime Development Mailing List >> > >> To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> > >> >> > > >> > >> >> >> >> -- >> pozdrawiam >> -- >> Michał Brzuchalski >> > -- pozdrawiam -- Michał Brzuchalski

Rowan Collins

10 years ago
On 22/06/2016 10:37, Michał Brzuchalski wrote:
> I may don't have voting privileges but as an 10yr PHP development > practitioner I can't believe that such big and awesome feature like Typed > Properties minimally can't have enought votes to be a part of PHP language > (26/(26+16) = 62% and that's not enoght to 2/3+1vote).
Bear in mind that this vote doesn't mean "PHP can never have typed properties", it means that "this particular approach to adding typed properties is not considered to be the right thing to do at the present time". If the vote had been unanimously against, it would have been hard to revive the proposal, but that's clearly not the case here. I agree that type safety would be a good direction for the language to go in, but I think we need a decent plan for how exactly that would work, rather than adding piecemeal features that introduce awkward edge cases and unintended consequences. (The restriction on referencing typed properties is my go-to example of this.) Incidentally, a crucial difference between PHP's type hints and those in just about any other language is that they are effectively assertions - dynamic, run-time checks (and sometimes implicit coercions) - rather than static, off-line analysis. You mentioned Java, which is a compiled language so provides full type safety at compile time; Python and Hack both consider type checks as metadata used by offline analysers, and ignore it at run-time. Perl6 I think does some run-time checking, but I couldn't find any documentation explicitly laying out the principles. That gives us a unique set of problems when designing them, not least in terms of performance. Regards,
-- Rowan Collins [IMSoP]

Unnamed Person

10 years ago
Hi, what about having "strict classes"? A strict class would be like a database table, each property defined must have a type. Each property defined must be initialized before being accessed, or have a default value. e.g. strict class Foo { public int $id; public bool $enabled; public DateTime $created; } Regards Thomas Dmitry Stogov wrote on 10.06.2016 14:37:

Marco Pivetta

10 years ago
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/ On 10 June 2016 at 12:38, Joe Watkins <pthreads@pthreads.org> wrote:

Niklas Keller

10 years ago
2016-06-10 14:39 GMT+02:00 Marco Pivetta <ocramius@gmail.com>:
> 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?

Marco Pivetta

10 years ago
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. On Jun 10, 2016 2:55 PM, "Niklas Keller" <me@kelunik.com> wrote:

Niklas Keller

10 years ago
> > 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

Bob Weinand

10 years ago
> Am 10.6.2016 um 15:34 schrieb Niklas Keller <me@kelunik.com>: > >> >> 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. Bob

Niklas Keller

10 years ago
2016-06-10 15:50 GMT+02:00 Bob Weinand <bobwei9@hotmail.com>:
> > Am 10.6.2016 um 15:34 schrieb Niklas Keller <me@kelunik.com>: > > > 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.

Bob Weinand

10 years ago
> Am 10.06.2016 um 16:00 schrieb Niklas Keller <me@kelunik.com>: > > 2016-06-10 15:50 GMT+02:00 Bob Weinand <bobwei9@hotmail.com <mailto:bobwei9@hotmail.com>>: > >> Am 10.6.2016 um 15:34 schrieb Niklas Keller <me@kelunik.com <mailto:me@kelunik.com>>: >> >>> >>> 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 <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.
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

Niklas Keller

10 years ago
2016-06-10 16:12 GMT+02:00 Bob Weinand <bobwei9@hotmail.com>:
> 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?

Bob Weinand

10 years ago
> Am 10.06.2016 um 16:16 schrieb Niklas Keller <me@kelunik.com>: > > > 2016-06-10 16:12 GMT+02:00 Bob Weinand <bobwei9@hotmail.com <mailto:bobwei9@hotmail.com>>: > 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

Joe Watkins

10 years ago
That's a bug ... that should throw ... Cheers Joe On Fri, Jun 10, 2016 at 3:12 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

Joe Watkins

10 years ago
Woops, no it isn't ... the property is private ... Cheers Joe On Fri, Jun 10, 2016 at 3:42 PM, Joe Watkins <pthreads@pthreads.org> wrote:

Benoit SCHILDKNECHT

10 years ago
Hi, Is it 2/3+1 or 1/2+1 ? I haven't seen it in the RFC. Cheeers. Le Fri, 10 Jun 2016 12:38:04 +0200, Joe Watkins <pthreads@pthreads.org> a écrit:
> Afternoon internals, > > The vote for typed properties has been restarted. > > Please take part: https://wiki.php.net/rfc/typed-properties > > Cheers > Joe
-- Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

Benjamin Eberlei

10 years ago
It changes the language, and therefore is 2/3 (without +1 afaik, just 2/3 required). On Sat, Jun 11, 2016 at 12:09 AM, Benoit Schildknecht <bensor987@neuf.fr> wrote:

Pascal MARTIN

10 years ago
Le 10/06/2016 12:38, Joe Watkins a écrit :
> The vote for typed properties has been restarted.
Hi, We, at AFUP, often tend to be on the "more static / strict types" side of things, and it remains this way for this RFC -- which means we would be +1 for typed properties. A few noted this was not quite "the PHP way", while the majority felt this was in line with previous changes (like scalar type declarations, nullable types...) and could prove interesting for complex applications. Judging from where the votes are right now, I'm guessing this RFC will not pass, but, in any case, thanks for your work on this! There are more "yes" than "no", so maybe it will open a path towards something, maybe a bit different, in another future version...
-- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/

Rasmus Schultz

9 years ago
Heh, so, this week, a coworker of mine started using PHP 7, and he calls me over, and he's like, "I don't get it, I had heard PHP 7 was supposed to have type-hints now - it worked for return-types, but what am I doing wrong, I can't seem to get this to work for properties?" He actually had something like "public int $id" in a class-declaration on his screen, and was genuinely confused - he simply assumed that would work, since it worked for return-types. When I explained to him that, no, PHP 7 still isn't type-hinted, it's *more* type-hinted, but still not fully type-hinted, he gave me the lemon-face. You know the one. Like you just ate a lemon. Yeah. I don't think there's a developer on my team and this point who isn't at least checking out other languages in frustration with the lack of features and consistency. I'm starting to feel like we're at risk of some of our best, young developers walking, if somebody offers them a chance to work with more "exciting" languages like Scala, Go, Dart, etc. - I'm not trying to say that proper type-hinting is the whole answer, but I believe it would go a long way towards consistency and the sense of completeness you get from some of the competing languages, where these features were engineered into the language from the design stage, rather than being added on a bit at a time. Any plans to revive this RFC or is it officially dead? On Thu, Jun 23, 2016 at 11:08 PM, Pascal MARTIN, AFUP < mailing@pascal-martin.fr> wrote:

Daniel Morris

9 years ago
If every language is the same then what's the point of different languages? People use Scala and PHP for different things, if your developers are considering walking for that reason then they should evaluate whether they want to build things or whether they want to be trendy. Good (heck, great) developers will put to best use the tools they have available. Migrate to Go, and watch every one of them eventually complain about how they're having to check for err against every function call since functions return multiple values, have them migrate to Scala and watch their frustration as the time to change visibility is dropped significantly; if you've hired developers that care more about trends than your application then you've hired the wrong developers.
-- Daniel Morris daniel@honestempire.com

Rasmus Schultz

9 years ago
> if you've hired developers that care more about trends than your
application then you've hired the wrong developers. A consistent, complete type-system is not a "trend". In my experience, good developers notice things like inconsistency - and they generally do not like it. I am personally *not* about trends, and don't tend to count developers who buy into hype as "good" developers - those would *not* be the developers I'd be concerned about walking. We can hire developers like those again easily.
> If every language is the same then what's the point of different
languages? I'm not arguing "PHP should be more like X", I'm arguing for consistency and completeness - an irrational fear of having certain similarities with other languages really does not work as an argument against that. Anyways, glad to hear Bob Weinland has been working on typed references and the RFC is not dead :-) On Sat, Nov 19, 2016 at 3:49 PM, Daniel Morris <daniel@honestempire.com> wrote:

Rowan Collins

9 years ago
On 20/11/2016 16:24, Rasmus Schultz wrote:
> A consistent, complete type-system is not a "trend".
[...]
> Anyways, glad to hear Bob Weinland has been working on typed references and > the RFC is not dead :-)
Just to reiterate, I don't agree that these two sentiments go together: a consistent type system requires a lot more than adding type keywords in a few more bits of syntax, then coming up with a meaning for that syntax. The conversation we need to have is not "how should typed properties work", but "what kind of type constraints do we want, and where should they be checked". Regards,
-- Rowan Collins [IMSoP]

Bob Weinand

9 years ago
Hey there, I’ve actually been working on an implementation covering also typed references, so that it’s possible to create references to a typed property, which had been a major concern back then. See also: https://github.com/bwoebi/php-src/compare/typed_properties...bwoebi:typed_ref_properties I’m planning to revive the RFC soon. Bob

Stephen Reay

9 years ago
Thanks for your work on this Bob, it is *very* appreciated!

Rowan Collins

9 years ago
On 19/11/2016 14:04, Rasmus Schultz wrote:
> lack of features > and consistency [...] where these features were engineered > into the language from the design stage, rather than being added on a bit > at a time.
I think the consistency and "engineered in" parts of this are more important than people give them credit for. Adding type hints to a dynamic language is not a trivial thing; what do those type hints actually *mean*?
> He actually had something like "public int $id" in a class-declaration on > his screen, and was genuinely confused - he simply assumed that would work
What did he expect that declaration to do? Did he expect his program not to compile if he wrote some code that assigned a string? Did he expect to have to run a static analysis tool to detect errors? Did he expect the run-time to insert an assertion on every assignment and raise a runtime error? Did he expect this to happen even in production, or only in a development-only "checked" mode? All of these are possible behaviours, implemented in other languages. I've written some of my thoughts on how it *could* work in this blog post: http://rwec.co.uk/q/php-type-system Before we add type hints anywhere else in the language, I think we need to think about what we are actually working towards. Otherwise, we're going to end up with a mess of inconsistent rules because each set of type hints was added separately with slightly different semantics and caveats. Regards,
-- Rowan Collins [IMSoP]

Stas Malyshev

9 years ago
Hi!
> Any plans to revive this RFC or is it officially dead?
I really wish people won't use [Vote] subject in topics having nothing to do with RFC voting start/stop.
-- Stas Malyshev smalyshev@gmail.com

Rowan Collins

9 years ago
On 19/11/2016 18:38, Stanislav Malyshev wrote:
> Hi! > >> Any plans to revive this RFC or is it officially dead? > I really wish people won't use [Vote] subject in topics having nothing > to do with RFC voting start/stop. >
It's because it's a reply to an old thread. Which is annoying in itself for those of us using mail clients (e.g. Thunderbird) which thread by ID, not subject line, as it bumps the entire old thread into view, like a forum. Better to just start a blank message and quote or link the old thread, IMHO. Regards,
-- Rowan Collins [IMSoP]

Christoph Becker

10 years ago
On 10.06.2016 at 12:38, Joe Watkins wrote:
> The vote for typed properties has been restarted. > > Please take part: https://wiki.php.net/rfc/typed-properties
I've noticed that the vote for this RFC is still open, even though it states: | Voting started 10th June, ends 24th June 2016.
-- Christoph M. Becker

Joe Watkins

10 years ago
Morning, Voting closed, feature declined ... Cheers Joe On Mon, Jun 27, 2016 at 10:12 AM, Christoph Becker <cmbecker69@gmx.de> wrote: